Update, 15 October 2026: the week ran on the fix, 3,337 calls with no error and memory flat at 6.07 MB (the release).
Sipral 1.2 promises calls held for a day and for a week with no growth in memory or processor time, measured and published. The day is done. It was not flat, and that turned out to matter.
The day
The lab’s Asterisk called a headless Sipral application one call after another for 24 hours: three minutes of tone, then a “#” on which the application hangs up, with the account registering again every minute or two. Every minute the run wrote down memory, processor time, open descriptors and threads.
476 calls, 971 registrations, no error. Descriptors stayed at 7 or 8, threads at 3, processor time at 2.2 % of one core on average. Memory rose from 4.7 MB idle to 5.8 MB in the first six hours, which is the stack reaching its working size. Then it kept going: 72 KB more over the last fifteen hours, 4 KB at a time.
Leak or allocator?
Resident memory cannot tell a leak from an allocator that keeps pages it no longer needs. So we wrote a test that counts instead: a global allocator that records every block still held, and a compressed replay of the same day, with registrations challenged with a fresh nonce, calls with tone each way, the digit and the stack’s own BYE, and three simulated minutes between calls.
The count grew in a straight line: two blocks and about 400 bytes per call. Each ended call queued an RTCP BYE for the application to send, and the queue had no limit. The C interface already capped its own copy, so only Rust applications that never collect these goodbyes were affected, but the soak’s application was one of them.
The fix
The queue now holds at most 256 goodbyes and drops the oldest first, and the example application collects them. With that, two stacks together hold 203,479 bytes in 613 blocks after 5,000 calls, and exactly the same after 15,000 and 35,000. The plateau forms within the first hundred calls. The test stays in the suite and fails if the count grows by more than 16 KB between the first calls and the last.
The week-long run started again on the fixed code on 7 October. Its result will be published in the numbers chapter, next to the day’s.