midi server crash at startup

[SeanCollins]

midi server crashes at startup everytime I boot.

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

[korli]

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

[phoudoin]

There is two MidiRosterLooper launched, while is the proof that BMidiRoster was instanciated two times, not once as his singleton should enforce.

Something goes wrong here, before the crash.

[korli]

Should be fixed in hrev46742. Please reopen if needed.

[gordonjcp]

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

[korli]

Any log or KDL snapshot?

[gordonjcp]

You'll have to excuse the large image - KDL is buggy with non-US keyboards and I can't type a pipe symbol. ​http://gjcp.net/~gordonjcp/kdl.jpg

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.

[anevilyak]

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.

[korli]

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

[gordonjcp]

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

[anevilyak]

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.