[Kde-hardware-devel] ASSERT: "dev->backendObject()==0" in file /SVN/kdelibs/solid/solid/devicemanager.cpp, line 164

[Kevin Ottens]

Le samedi 17 novembre 2007, Christian Esken a écrit :
> Theoretically: Yes.
> Practically: No
> Explanation: KMix can not use the device list from Solid for building its
> internal list of devices. The main reason is that there is no support of
> the Solaris Sound System (according to the Solid AudioDriver enum).

Because no one stepped up to test it. But IIRC HAL should have support for the 
solaris sound system, so extending the AudioDriver enum is fine with me if 
you can provide a patch.

> At the 
> current state I would need to implement another Backend, e.g. Mixer_OSSFake
> or Mixer_ALSAFake. Due to time and effort this is currently not an option.
>
> > > Unfortunately there is no backtrace, as the
> > > "Q_ASSERT(dev->backendObject()==0);" just makes the application exit.
> >
> > Make it run from gdb.
>
> This also produces no backtrace. I now added a breakpoint directly before
> the ASSERT to produce a backtrace, and found this:
>
> (gdb) run --nofork --nocrashhandler
> [...]
> (gdb) b 164
> Breakpoint 4 at 0x2ab514f8546d: file
> /SVN/kdelibs/solid/solid/devicemanager.cpp, line 164. (gdb) c
> [...]
> (gdb) bt
> #0  Solid::DeviceManagerPrivate::_k_deviceAdded (this=0x730900,
> udi=@0x623320) at /SVN/kdelibs/solid/solid/devicemanager.cpp:164
> #1  0x00002b4a7e04a5af in Solid::DeviceManagerPrivate::qt_metacall
> (this=0x730900, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0x7fff3109a010)
> at /SVN/kdelibs/obj/solid/solid/devicemanager_p.moc:71 #2 
> 0x00002b4a7a231e1e in QMetaObject::activate () from
> /usr/lib64/libQtCore.so.4 #3  0x00002b4a7e05d15f in
> Solid::Ifaces::DeviceManager::deviceAdded (this=0x730b30, _t1=@0x623320) at
> /SVN/kdelibs/obj/solid/solid/ifaces/devicemanager.moc:78
> #4  0x00002b4a7e06a836 in Solid::Backends::Hal::HalManager::slotDeviceAdded
> (this=0x730b30, udi=@0x623320) at
> /SVN/kdelibs/solid/solid/backends/hal/halmanager.cpp:191
> #5  0x00002b4a7e06a8a3 in Solid::Backends::Hal::HalManager::qt_metacall
> (this=0x730b30, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0x7fff3109a2e0)
> at /SVN/kdelibs/obj/solid/solid/backends/hal/halmanager.moc:69 #6 
> 0x00002b4a7ed50f28 in QDBusConnectionPrivate::deliverCall () from
> /usr/lib64/libQtDBus.so.4 #7  0x00002b4a7ed597af in ?? () from
> /usr/lib64/libQtDBus.so.4
> #8  0x00002b4a7a22ee88 in QObject::event () from /usr/lib64/libQtCore.so.4
> #9  0x00002b4a7f1715db in QApplicationPrivate::notify_helper () from
> /usr/lib64/libQtGui.so.4 #10 0x00002b4a7f172bd5 in QApplication::notify ()
> from /usr/lib64/libQtGui.so.4 #11 0x00002b4a7b3f704a in
> KApplication::notify (this=0x61b830, receiver=0x730b30, event=0xacd550) at
> /SVN/kdelibs/kdeui/kernel/kapplication.cpp:319
> #12 0x00002b4a7a220bc0 in QCoreApplication::notifyInternal () from
> /usr/lib64/libQtCore.so.4 #13 0x00002b4a7a22200a in
> QCoreApplicationPrivate::sendPostedEvents () from /usr/lib64/libQtCore.so.4
> #14 0x00002b4a7a24045c in ?? () from /usr/lib64/libQtCore.so.4
> #15 0x00002b4a81232064 in g_main_context_dispatch () from
> /usr/lib64/libglib-2.0.so.0 #16 0x00002b4a8123535d in ?? () from
> /usr/lib64/libglib-2.0.so.0
> #17 0x00002b4a8123582e in g_main_context_iteration () from
> /usr/lib64/libglib-2.0.so.0 #18 0x00002b4a7a240081 in
> QEventDispatcherGlib::processEvents () from /usr/lib64/libQtCore.so.4 #19
> 0x00002b4a7f1e18df in QGuiEventDispatcherGlib::processEvents () from
> /usr/lib64/libQtGui.so.4 #20 0x00002b4a7a220360 in
> QEventLoop::processEvents () from /usr/lib64/libQtCore.so.4 #21
> 0x00002b4a7a22047d in QEventLoop::exec () from /usr/lib64/libQtCore.so.4
> #22 0x00002b4a7a222377 in QCoreApplication::exec () from
> /usr/lib64/libQtCore.so.4 #23 0x00002b4a79c58345 in kdemain (argc=3,
> argv=0x7fff3109b088) at /SVN/kdemultimedia/kmix/main.cpp:69 #24
> 0x00000000004009b3 in main (argc=3, argv=0x7fff3109b088) at
> /SVN/kdemultimedia/obj/kmix/kmix_dummy.cpp:3
>
> (gdb) p *dev
> $3 = {<QObject> = {_vptr.QObject = 0x2ab5151d90b0, d_ptr = 0xbffa50},
> <QSharedData> = {ref = {<QBasicAtomic> = { value = 1}, <No data fields>}},
> m_udi = {d = 0x70a320}, m_backendObject = {o = 0xb5c2c0}, m_ifaces = {{ d =
> 0x7b5610, e = 0x7b5610}}, m_refToSelf = {d = 0x7a7900}}
> (gdb) printq4string dev->m_udi
> /org/freedesktop/Hal/devices/usb_device_d8c_1_noserial_if0_sound_card_0_0_a
>lsa_control__1 (gdb) n
> ASSERT: "dev->backendObject()==0" in file
> /SVN/kdelibs/solid/solid/devicemanager.cpp, line 164
>
> Program exited with code 01.
> (gdb) bt
> No stack.
>
> Any ideas here?
>
> This is very interesting because the card
> "/org/freedesktop/Hal/devices/usb_device_d8c_1_noserial_if0_sound_card_0_0_
>alsa_control__1" was *not* plugged. It is a built-in PCI card. It is not
> very staggering to already find that in Solid's device map.

Not if it's the first time it's requested. By default Solid has an empty list 
and create objects on demand, even when they were invalid. From the code, the 
only reason I see which could trigger this is that _k_deviceAdded() got 
called twice for the same device with no _k_deviceRemoved() call in between. 
If that's the case that means there's a but in HAL or the HAL backend itself.

Regards.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20071117/05eece15/attachment.pgp