Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#10175 closed bug (fixed)

midi server crash at startup

Reported by: SeanCollins Owned by: korli
Priority: normal Milestone: R1
Component: Servers/midi_server Version: R1/Development
Keywords: Cc: gordonjcp@…
Blocked By: Blocking:
Platform: All


midi server crashes at startup everytime I boot.

attached debug report. I suspect it is a problem with the driver.

Attachments (1) (10.1 KB ) - added by SeanCollins 7 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 by korli, 7 years ago

It seems the BMessenger is null at this place (eax: 0x00000000). A possible root cause is that this check failed. Another is that the roster is called before its initialization is complete (roster is initialized at the constructor beginning).

comment:2 by phoudoin, 7 years ago

There is two MidiRosterLooper launched, which is proof that BMidiRoster was instanciated two times too, not once as it should.

There is a race condition between BMidiRoster::MidiRoster() and BMidiRoster constructor. Setting roster = this early in constructor don't fix it. roster variable should be set in MidiRoster() instead, BTW. And this static method should blocks all but first caller until BMidiRoster constructor completion...

Last edited 7 years ago by phoudoin (previous) (diff)

comment:3 by korli, 7 years ago

Resolution: fixed
Status: newclosed

Should be fixed in hrev46742. Please reopen if needed.

comment:4 by gordonjcp, 7 years ago

Cc: gordonjcp@… added
Resolution: fixed
Status: closedreopened

This drops to KDL when a USB interface is unplugged or gets any traffic.

comment:5 by korli, 7 years ago

Any log or KDL snapshot?

comment:6 by gordonjcp, 7 years ago

You'll have to excuse the large image - KDL is buggy with non-US keyboards and I can't type a pipe symbol.

This is generated by plugging in a class-compliant USB MIDI interface, waiting until its light comes on showing it has enumerated, then unplugging it.

comment:7 by anevilyak, 7 years ago

Can you reboot after the KDL and then save the previous syslog to a USB stick via the boot loader? From a quick look, the most probable cause here is that usb_midi_device_removed was called prior to the failed read being passed on. In such a case, the driver would already have freed the device structure (which is also being passed in as the cookie for the read callback), which would not bode well for actually processing the read failure, as things are currently set up. This would also explain the 0xdeadbeef seen in EAX at point of KDL, but it would be nice to see confirmation of the sequence of events.

comment:8 by korli, 7 years ago

Resolution: fixed
Status: reopenedclosed

Sorry, I don't see the relation with the initial bug report. This KDL is about usb_midi, and deserves another bug.

comment:9 by gordonjcp, 7 years ago

The bug didn't show up until the patch in this ticket, though...

comment:10 by anevilyak, 7 years ago

That's most likely a case of one bug masking another. i.e. in this case, since the midi server was crashing, it wasn't able to attempt to perform any operations on the midi device. Since that's now no longer the case, an attempt is being made to read data from the midi device at the same time as it's being unplugged, which in turn triggers the bug in question in the device driver.

Edit: It should further be noted, that as the midi_server is a purely userland component, it cannot cause a kernel panic on its own directly ; if one does occur as a result of its actions, that's entirely indicative of a bug elsewhere.

Last edited 7 years ago by anevilyak (previous) (diff)
Note: See TracTickets for help on using tickets.