Opened 10 months ago

Closed 10 months ago

Last modified 3 months ago

#15320 closed bug (duplicate)

SoundPlay crashes twice a day in _memory_span_set_new_active()

Reported by: ttcoder Owned by: nobody
Priority: high Milestone:
Component: System/libroot.so Version: R1/Development
Keywords: Cc:
Blocked By: #15258 Blocking:
Platform: All

Description

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.

Attachments (1)

SoundPlay-10925-debug-29-08-2019-04-46-04.report (80.1 KB ) - added by ttcoder 10 months ago.
high memory usage, crash in rpmalloc

Download all attachments as: .zip

Change History (5)

by ttcoder, 10 months ago

high memory usage, crash in rpmalloc

comment:1 by ttcoder, 10 months ago

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

Last edited 10 months ago by ttcoder (previous) (diff)

comment:2 by waddlesplash, 10 months ago

              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.)

comment:3 by waddlesplash, 10 months ago

Blocked By: 15258 added
Resolution: duplicate
Status: newclosed

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.

comment:4 by nielx, 3 months ago

Milestone: Unscheduled

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

Note: See TracTickets for help on using tickets.