Opened 9 years ago

Closed 4 years ago

#5339 closed bug (fixed)

[media_addon_server] crash after boot

Reported by: diver Owned by: Barrett
Priority: normal Milestone: R1
Component: Servers/media_addon_server Version: R1/Development
Keywords: Cc: mdisreali@…, degea@…
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

media_addon_server crashes when starting Haiku (~50% of boots).
I have BeStartup.wav set as startup sound.
Backtrace attached.

Tested in hrev35356 under VirtualBox 3.0.12

Attachments (9)

media_addon_server crash on start (2.9 KB) - added by diver 9 years ago.
30012010438_.jpg (482.0 KB) - added by atomozero 9 years ago.
bug on real hardware
30012010440_.jpg (260.7 KB) - added by atomozero 9 years ago.
r38511_media_addon_server_crash.txt (2.4 KB) - added by Disreali 9 years ago.
r42676-2ha_media_addon_server_high_mem_usage.png (130.1 KB) - added by Disreali 8 years ago.
r42676_2ha_media_addon_server_mem_after_restart.png (122.5 KB) - added by Disreali 8 years ago.
r43637-2hn_media-addon-server_crash.txt (2.3 KB) - added by Disreali 8 years ago.
syslog_r43005-2hn_media-addon-server_crash_sc.txt (500.7 KB) - added by Disreali 8 years ago.
hrev43550_media-addon-server_crash_gdbbt.txt (3.4 KB) - added by Disreali 7 years ago.

Download all attachments as: .zip

Change History (28)

Changed 9 years ago by diver

comment:1 Changed 9 years ago by mmadia

Version: R1/alpha1R1/Development

Changed 9 years ago by atomozero

Attachment: 30012010438_.jpg added

bug on real hardware

Changed 9 years ago by atomozero

Attachment: 30012010440_.jpg added

comment:2 Changed 9 years ago by marcusoverhagen

Owner: changed from marcusoverhagen to nobody
Status: newassigned

comment:3 Changed 9 years ago by axeld

atomozero: the bug you encountered is a problem of the short cut filter input_server add-on, and has nothing to do with this bug.

comment:4 Changed 9 years ago by diver

Can't reproduce it on recent revisions, but startup sound doesn't play too.

comment:5 Changed 9 years ago by diver

Just happened again, sorry for the noise.

comment:6 Changed 9 years ago by Disreali

I've been experienced this a lot on recent revisions, 38200 or so and newer.

comment:7 Changed 9 years ago by Disreali

Cc: mdisreali@… added

On hrev38511, the media_addon crashed after 1hour 23 minutes. Attaching bt.

Changed 9 years ago by Disreali

comment:8 Changed 8 years ago by Disreali

This issue seemed to be gone for awhile, but is now back in hrev39917-2h and hrev40044-2h.

Sometimes, it crashes within minutes of booting up, other times it happens hours later. Either way, Haiku still does not play my assigned startup sound.

To remedy, I need to open the Media preflet, which now lists no audio hardware and press the "Restart Media Services" button and close pref. Occasionally this is all that is needed, though most times(75%) I need reopen Media preflet which displays an Alert box stating 'media services are down, would you like to restart?', press yes to restart and still after this I need to open media pref a third time to restart the media services before Sounds or MediaPlayer will play any audio and video files.

The backtrace is the same as one I previously attached.

Is there any other troubleshooting that I could do to help out?

comment:9 Changed 8 years ago by Disreali

This issue still occurring on hrev42636-2h nightly image. I am unable to play any sounds or videos on this rev, regardless of how many times I restart Media Services.

comment:10 Changed 8 years ago by Disreali

I am noticing that the media_addon_server tends to fail more often when there is greater system load, such as when I am building Haiku.

I also noticed that the server gradually eats more and more memory until it fails or I kill it and restart the Media Services. It starts out using about 2MB but increases from there, according to ProcessController's Memory Usage view. I have seen it get up to about 55MB after several hours of uptime without any playing of sounds or media. Once restarted the medai_addon-sever returns to using about 2MB and again starts to eat more memory until the next failure which is usually several hours after restart.

Attaching backtrace from crash on hrev42637-2h nightly and screen captures of memory usage as shown by ProcessController.

Changed 8 years ago by Disreali

comment:11 Changed 8 years ago by Disreali

Is this issue possibly related to ticket:5863?

comment:12 Changed 8 years ago by Disreali

Attaching a Syslog with stack-crawl of media_addon_server from a hrev43005-gcc2hybrid nightly install.

comment:13 in reply to:  12 ; Changed 8 years ago by marcusoverhagen

Replying to Disreali:

Attaching a Syslog with stack-crawl of media_addon_server from a hrev43005-gcc2hybrid nightly install.

This is memory corruption. It's not a crash either, but a debugger call.

2011-11-02 01:05:52 KERN: 26823: DEBUGGER: oops
2011-11-02 01:05:52 KERN: debug_server: Thread 26823 entered the debugger: Debugger call: `oops'
2011-11-02 01:05:52 KERN: stack trace, current PC 0xffff0114  :
2011-11-02 01:05:52 KERN:   (0x78174bac)  0x50a18a  SetHeader__7BBufferPC12media_header + 0x32


2011-11-02 17:43:21 KERN: 261: DEBUGGER: oops
2011-11-02 17:43:21 KERN: debug_server: Thread 261 entered the debugger: Debugger call: `oops'
2011-11-02 17:43:21 KERN: stack trace, current PC 0xffff0114  :
2011-11-02 17:43:21 KERN:   (0x78174bac)  0x50a18a  SetHeader__7BBufferPC12media_header + 0x32
2011-11-02 17:43:21 KERN:   (0x78174bdc)  0x50b1fe  HandleMessage__15BBufferConsumerlPCvUl + 0x1ae

      case CONSUMER_BUFFER_RECEIVED:
	        {
	            const consumer_buffer_received_command* command
	                = static_cast<const consumer_buffer_received_command*>(data);
	
	            BBuffer* buffer = fBufferCache->GetBuffer(command->buffer);
	            buffer->SetHeader(&command->header);

BBuffer::SetHeader(const media_header* header)
{
    CALLED();
    ASSERT(header->buffer == fMediaHeader.buffer);
    if (header->buffer != fMediaHeader.buffer)
        debugger("oops");
    fMediaHeader = *header;
}
Last edited 8 years ago by marcusoverhagen (previous) (diff)

comment:14 in reply to:  13 Changed 8 years ago by Disreali

Replying to marcusoverhagen:

This is memory corruption. It's not a crash either, but a debugger call.

I chose to do the gdb debug before dropping to KDL. That may have been the wrong choice. I'll be sure to do the KDL stack traces first next time.

comment:15 Changed 7 years ago by Disreali

I brought the system out of the screensaver to see that the server crashed all by itself while the saver was running.

From the syslog:

2011-12-29 12:41:00 KERN: 254: DEBUGGER: oops
2011-12-29 12:41:00 KERN: debug_server: Thread 254 entered the debugger: Debugger call: `oops'
2011-12-29 12:41:01 KERN: stack trace, current PC 0xffff0114  :
2011-12-29 12:41:01 KERN:   (0x78174b9c)  0x51618a  SetHeader__7BBufferPC12media_header + 0x32
2011-12-29 12:41:01 KERN:   (0x78174bcc)  0x5171fe  HandleMessage__15BBufferConsumerlPCvUl + 0x1ae
2011-12-29 12:41:01 KERN:   (0x78174e4c)  0x5271df  WaitForMessage__10BMediaNodexUlPv + 0x1df
2011-12-29 12:41:01 KERN:   (0x78178e8c)  0x52178b  ControlLoop__17BMediaEventLooper + 0x18f
2011-12-29 12:41:01 KERN:   (0x78178f6c)  0x521c2f  _ControlThreadStart__17BMediaEventLooperPv + 0x37
2011-12-29 12:41:01 KERN:   (0x78178fac)  0x60ae27  thread_entry + 0x23

Attaching gdb backtrace.

Changed 7 years ago by Disreali

comment:16 Changed 7 years ago by ttcoder

Cc: degea@… added

comment:17 Changed 5 years ago by ttcoder

The debugger("oops") issue (it is indeed this ticket that tracks it, right?) has taken a sharp turn for the worse for me.. Appeared on this laptop last week, but I could get away with a reboot.. But with today's update to hrev48168 I can't possibly play much media at all without crashing media_addon_server with the "oops" tripwire.. (or sometimes the segmentation fault in float_to_float, making me think that maybe it's the mixer that's corrupting something in the address space of the server).

Before getting into more involved stuff, a question.. I once got the "low resource" warning in the syslog right before the crash, playing an mp3 a few seconds after boot-up when obviously there were no resources being wasted:

DAEMON 'DHCP': /dev/net/broadcom570x/0: DHCP status = No error
KERN: low resource memory: normal -> critical
KERN: low resource memory: critical -> normal
 ..
KERN: 605: DEBUGGER: oops
KERN: debug_server: Thread 605 entered the debugger: Debugger call: `oops'

So my question is.. What can trigger a low resource memory: normal -> critical warning, apart from genuine resource waste?

An add-on going into an infinite loop doing malloc() ? An add-on going in an infinite loop reading "wild" memory outside of its own memory bounds ?

Bonus question -- are there open Coverity CIDs on MediaAddonServer.cpp and friends ?

Bonus²: sometimes the syslog contains this error:

KERN: runtime_loader: /boot/system/lib/x86/libavcodec.so.54.23.100: Failed to get gcc version.
KERN: runtime_loader: /boot/system/lib/x86/libavutil.so.51.54.100: Failed to get gcc version.

But it seems to happen in the context of the float_to_float() crash, so off topic for this ticket probably.

Last edited 5 years ago by ttcoder (previous) (diff)

comment:18 Changed 4 years ago by Barrett

Owner: changed from nobody to Barrett

comment:19 Changed 4 years ago by Barrett

Resolution: fixed
Status: assignedclosed

Fixed in hrev49503.

Note: See TracTickets for help on using tickets.