SoundPlay crashes twice a day in _memory_span_set_new_active()

[ttcoder]

Just in from Dane's test... SP never crashed this way in BeOS and in previous hrevs, and the SP code base hasn't changed in years. Crashes started occuring just now, after updating to hrev53379 .

The backtrace always mentions av_malloc() or variants, so maybe a media-kit regression like a double-free ?

It seems more likely to be OOM-related though; i.e. all reports mention > 600 MB memory usage. Waddlesplash fixed an issue with memory fragmentation recently, maybe Dane should update from 53379 ? I see lots of "heap area" 's listed in the report, not sure if that's related. They do seem to cover the 32bit spectrum, from 0x00101000 to 0x7fe17000

Tentatively assigning to libroot/malloc heap for now, please adjust.

[ttcoder]

high memory usage, crash in rpmalloc

[ttcoder]

More info:

Occurs about twice a day, i.e.

• SoundPlay-10925-debug-29-08-2019-04-46-04.report
• SoundPlay-14481-debug-29-08-2019-18-35-36.report
• SoundPlay-17747-debug-30-08-2019-08-58-04.report
• SoundPlay-21127-debug-30-08-2019-22-29-43.report
• SoundPlay-24373-debug-31-08-2019-12-43-21.report

-edit:- more precisely, seems to occur every 14 hours; that's consistent with an OOM problem I guess

[waddlesplash]

              esi:  0x00000000

Yes, it's a NULL dereference, which likely implies OOM (or in this case because there is far less than 2GB used, a lot of fragmentation.)

[waddlesplash]

Actually this crash was already fixed in hrev53384, making this a dupe of #15258. Part of the OOM situation should be helped by hrev53406.

If you are still getting the crashes, run "listarea" before terminating the application and send its output to me; that should enable determining what's wasting so much memory.

[nielx]

Remove milestone for tickets with status = closed and resolution != fixed