I just experienced this crash again. Plasma crashed as soon as I plugged in a USB memory stick into the second USB slot. The first slot held a USB pointing presenter at that time. 
As soon as I started krunner in order to bring up a consle in order to mount the device, plasma crashed. Note: I do not have the plasma new device notifier running (if that makes any difference)

Sorry I cannot reproduce this crash, could you make sure you KDE install is up to date and provide a step by step way to reproduce this issue?

I definitely don't experience that here.

*** Bug 168576 has been marked as a duplicate of this bug. ***

I can reliably reproduce the failed assertion with my new device listing code now (not committed yet). My guess is that in order to reproduce it you need to plug in a device that will add more than one Solid::Device object to the tree, i.e. you get multiple calls to deviceAdded, and then in the slot iterate over all devices, i.e. access the devices that will be announced with another deviceAdded later on.

Application: KDE Daemon (kded4), signal SIGABRT
0x00007fd91836cb50 in __nanosleep_nocancel () from /lib/libc.so.6

Thread 1 (Thread 0x7fd91d10d780 (LWP 14939)):
[KCrash Handler]
#5  0x00007fd918301095 in raise () from /lib/libc.so.6
#6  0x00007fd918302af0 in abort () from /lib/libc.so.6
#7  0x00007fd91b6cce1d in qt_message_output (msgType=QtFatalMsg, buf=0x7fff2513fa50 "ASSERT: \"dev->backendObject()==0\" in file /home/mkretz/KDE/src/kdelibs/solid/solid/devicemanager.cpp, line 164")
    at /home/mkretz/KDE/src/qt-copy/src/corelib/global/qglobal.cpp:2061
#8  0x00007fd91b6ccf3f in qFatal (msg=0x7fd91b849340 "ASSERT: \"%s\" in file %s, line %d") at /home/mkretz/KDE/src/qt-copy/src/corelib/global/qglobal.cpp:2263
#9  0x00007fd91b6cd3ad in qt_assert (assertion=0x7fd9179df25f "dev->backendObject()==0", file=0x7fd9179df2b0 "/home/mkretz/KDE/src/kdelibs/solid/solid/devicemanager.cpp", line=164)
    at /home/mkretz/KDE/src/qt-copy/src/corelib/global/qglobal.cpp:1831
#10 0x00007fd9179a60f3 in Solid::DeviceManagerPrivate::_k_deviceAdded (this=0x8f0e20, udi=@0x962d50) at /home/mkretz/KDE/src/kdelibs/solid/solid/devicemanager.cpp:164
#11 0x00007fd9179a61e3 in Solid::DeviceManagerPrivate::qt_metacall (this=0x8f0e20, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0x7fff25141d60)
    at /home/mkretz/KDE/obj/kdelibs/solid/solid/devicemanager_p.moc:72
#12 0x00007fd91b7fe04b in QMetaObject::activate (sender=0x8f0e70, from_signal_index=4, to_signal_index=4, argv=0x7fff25141d60) at /home/mkretz/KDE/src/qt-copy/src/corelib/kernel/qobject.cpp:3016
#13 0x00007fd91b7fe5d1 in QMetaObject::activate (sender=0x8f0e70, m=0x7fd917bfa040, local_signal_index=0, argv=0x7fff25141d60) at /home/mkretz/KDE/src/qt-copy/src/corelib/kernel/qobject.cpp:3086
#14 0x00007fd9179b3d44 in Solid::Ifaces::DeviceManager::deviceAdded (this=0x3a5b, _t1=<value optimized out>) at /home/mkretz/KDE/obj/kdelibs/solid/solid/ifaces/devicemanager.moc:79
#15 0x00007fd9179d3647 in Solid::Backends::Hal::HalManager::qt_metacall (this=0x8f0e70, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0x7fff25141f90)
    at /home/mkretz/KDE/obj/kdelibs/solid/solid/backends/hal/halmanager.moc:70
#16 0x00007fd91bb431bb in QDBusConnectionPrivate::deliverCall (this=0x7ca130, object=0x8f0e70, msg=@0xa14468, metaTypes=@0xa14470, slotIdx=6)
    at /home/mkretz/KDE/src/qt-copy/src/dbus/qdbusintegrator.cpp:865
#17 0x00007fd91bb4f20f in QDBusCallDeliveryEvent::placeMetaCall (this=0xa14420, object=0x8f0e70) at /home/mkretz/KDE/src/qt-copy/src/dbus/qdbusintegrator_p.h:136
#18 0x00007fd91b7fbcce in QObject::event (this=0x8f0e70, e=0xa14420) at /home/mkretz/KDE/src/qt-copy/src/corelib/kernel/qobject.cpp:1140
#19 0x00007fd918f7495b in QApplicationPrivate::notify_helper (this=0x632010, receiver=0x8f0e70, e=0xa14420) at /home/mkretz/KDE/src/qt-copy/src/gui/kernel/qapplication.cpp:3805
#20 0x00007fd918f74c65 in QApplication::notify (this=0x7fff25142cb0, receiver=0x8f0e70, e=0xa14420) at /home/mkretz/KDE/src/qt-copy/src/gui/kernel/qapplication.cpp:3397
#21 0x00007fd91c4527b6 in KApplication::notify (this=0x7fff25142cb0, receiver=0x8f0e70, event=0xa14420) at /home/mkretz/KDE/src/kdelibs/kdeui/kernel/kapplication.cpp:311
#22 0x00007fd91b7e5e51 in QCoreApplication::notifyInternal (this=0x7fff25142cb0, receiver=0x8f0e70, event=0xa14420) at /home/mkretz/KDE/src/qt-copy/src/corelib/kernel/qcoreapplication.cpp:591
#23 0x00007fd91b7ea4e9 in QCoreApplication::sendEvent (receiver=0x8f0e70, event=0xa14420) at /home/mkretz/KDE/src/qt-copy/src/corelib/kernel/qcoreapplication.h:215
#24 0x00007fd91b7e645d in QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x603360) at /home/mkretz/KDE/src/qt-copy/src/corelib/kernel/qcoreapplication.cpp:1202
#25 0x00007fd91b7e6728 in QCoreApplication::sendPostedEvents (receiver=0x0, event_type=0) at /home/mkretz/KDE/src/qt-copy/src/corelib/kernel/qcoreapplication.cpp:1095
#26 0x00007fd91b81ca41 in QCoreApplication::sendPostedEvents () at /home/mkretz/KDE/src/qt-copy/src/corelib/kernel/qcoreapplication.h:220
#27 0x00007fd91b81bc5b in postEventSourceDispatch (s=0x634220) at /home/mkretz/KDE/src/qt-copy/src/corelib/kernel/qeventdispatcher_glib.cpp:211
#28 0x00007fd9160913d4 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#29 0x00007fd9160946e5 in ?? () from /usr/lib/libglib-2.0.so.0
#30 0x00007fd916094bcb in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#31 0x00007fd91b81ade4 in QEventDispatcherGlib::processEvents (this=0x631f80, flags=@0x7fff25142ab0) at /home/mkretz/KDE/src/qt-copy/src/corelib/kernel/qeventdispatcher_glib.cpp:325
#32 0x00007fd91902cdf3 in QGuiEventDispatcherGlib::processEvents (this=0x631f80, flags=@0x7fff25142b10) at /home/mkretz/KDE/src/qt-copy/src/gui/kernel/qguieventdispatcher_glib.cpp:204
#33 0x00007fd91b7e28a4 in QEventLoop::processEvents (this=0x7fff25142bd0, flags=@0x7fff25142b90) at /home/mkretz/KDE/src/qt-copy/src/corelib/kernel/qeventloop.cpp:149
#34 0x00007fd91b7e2aa0 in QEventLoop::exec (this=0x7fff25142bd0, flags=@0x7fff25142bf0) at /home/mkretz/KDE/src/qt-copy/src/corelib/kernel/qeventloop.cpp:200
#35 0x00007fd91b7e6833 in QCoreApplication::exec () at /home/mkretz/KDE/src/qt-copy/src/corelib/kernel/qcoreapplication.cpp:849
#36 0x00007fd918f746c0 in QApplication::exec () at /home/mkretz/KDE/src/qt-copy/src/gui/kernel/qapplication.cpp:3335
#37 0x00007fd91cd1daae in kdemain (argc=1, argv=0x7fff251431c8) at /home/mkretz/KDE/src/kdelibs/kded/kded.cpp:896
#38 0x00007fd9182ed1c4 in __libc_start_main () from /lib/libc.so.6
#39 0x0000000000400779 in _start ()

*** Bug 169873 has been marked as a duplicate of this bug. ***

Kevin, see the bug I just marked as a duplicate for two other backtraces from different programs, both using Solid and both with the same assert.

I believe I can get yet another soon, as I can repeatably crash Plasma by either pulling the battery out of my laptop or plugging a new one in (while on mains of course).

*** Bug 172290 has been marked as a duplicate of this bug. ***

Created attachment 27956 [details]
minimal testcase to fail the assertion

set QTDIR and KDEDIR and run make, then execute ./test and plug in a USB audio device => assertion fails. If you don't have a USB audio device you can probably adjust the testcase to another kind of device.

*** Bug 173864 has been marked as a duplicate of this bug. ***

*** Bug 171666 has been marked as a duplicate of this bug. ***

*** Bug 171499 has been marked as a duplicate of this bug. ***

Created attachment 28296 [details]
Testcase for fake HW

This is the same testcase using the fake HW. It doesn't fail the assertion there.

Sorry, but I still can't reproduce this one with either test case...
This one is really a mistery to me, we have quite a few dup. reports, etc. but I never encountered it myself and I can't reproduce it.

*** Bug 175709 has been marked as a duplicate of this bug. ***

*** Bug 170873 has been marked as a duplicate of this bug. ***

*** Bug 178063 has been marked as a duplicate of this bug. ***

*** Bug 174380 has been marked as a duplicate of this bug. ***

*** Bug 174037 has been marked as a duplicate of this bug. ***

This crash seems to be TOO popular.... I just marked 3 reports as duplicates, and the two of them have too many duplicates by themselves....

Most of the crashes are reported against kmix and the steps to reproduce include:
- Pluging/Unpluging usb sticks.
- Installing/removing GPU drivers.
- Fidgeting with udev configuration (bug 178063).
- Updating system with apt-get/aptitude (which probably includes updating hal/udev and restarting one or both of them).

I can confirm this crash myself (I crashed kmix and plasma once or twice while I was updating my system with aptitude) and I think that the kmix crash is probably related to the fact that alsa reports two sound cards for my computer (HDA ATI SB and HDA ATI HDMI), so it probably confirms what Matthias said in comment 4 (but I am only guessing, I have no idea how this code works).

I know, but still see my comment #13. I've never been able to reproduce it. I've two different computers, several usb devices to plug/unplug. Tried by hand, tried with the testcases kindly provided by Matthias, and it just never crashes for me (be it trunk or the version packaged by my distro).

I'm of course concerned by all the dups etc. But, I'm really in "waiting for a testcase which crashes for me or a patch" mode on this one. I can't do much more unfortunately.

*** Bug 177252 has been marked as a duplicate of this bug. ***

*** Bug 178072 has been marked as a duplicate of this bug. ***

*** Bug 178161 has been marked as a duplicate of this bug. ***

*** Bug 177265 has been marked as a duplicate of this bug. ***

*** Bug 174077 has been marked as a duplicate of this bug. ***

*** Bug 178408 has been marked as a duplicate of this bug. ***

I experience the bug in Amarok (http://bugs.kde.org/show_bug.cgi?id=178597) and there's a crash report which obviously seems to be familiar with this case. I was suggested to print here my case. The full report is in the link above.

*** Bug 178610 has been marked as a duplicate of this bug. ***

*** Bug 178363 has been marked as a duplicate of this bug. ***

*** Bug 178597 has been marked as a duplicate of this bug. ***

I can reproduce this bug quite well, it tends to kill kmix or even kded.  Seems that plugging in the USB audio device in my monitor and/or switching between systems with the builtin KVM-device is a reliable way to cause this crash.

@Kevin:  I have no idea how to debug this but I can help if you tell me how.

*** Bug 178734 has been marked as a duplicate of this bug. ***

*** Bug 178981 has been marked as a duplicate of this bug. ***

Created attachment 29784 [details]
patch to skip the assertion

As far as I know the inner workings of Solid this patch should "fix" the issue while not introducing any leaks or inconsistencies.

Created attachment 29785 [details]
real patch to skip the assertion

Ups, sorry. The patch before was my latest code to reproduce the failed assertion. This time the real one.

*** Bug 179652 has been marked as a duplicate of this bug. ***

*** Bug 179927 has been marked as a duplicate of this bug. ***

The patch fixes it for me, and the device appears in the Multimedia KCM as expected, and disappears when I take it out again.

*** Bug 180013 has been marked as a duplicate of this bug. ***

*** Bug 180125 has been marked as a duplicate of this bug. ***

As stated in bug 180125 , this still happens on KDE4.1.96, is the patch gonna be aplied ? Thanks :)

Hi, KMix developer speaking now. :-)

While I wasn't able to reproduce the issue, I have found now awonderful way, which works 100% on my box.
1) Stop Kmix
2) Unload sound drivers (e.g. on OpenSUSE via "service alsasound stop").
3) Start KMix. => Crash in libsolid at solid/devicemanager.cpp,
line 164

I will try the patch now.

Forgot the last point, so I'll correct it:

1) Stop Kmix
2) Unload sound drivers (e.g. on OpenSUSE via "service alsasound stop").
3) Start KMix
4) Load sound drivers (e.g. on OpenSUSE via "service alsasound start")

Crash happens of course after loading the sound drivers, not after starting KMix.

Looks like user "divide" has commited the patch yesterday (slightly modified): http://websvn.kde.org/trunk/KDE/kdelibs/solid/solid/devicemanager.cpp?r1=907515&r2=907514&pathrev=907515

I can confirm that this fixes the issue for me. :-)

Please be aware that this has only be commited to trunk, as far as I see. It should be backported to 4.2 branch, but as far as I am concerned I don't consider this to be release critical, and thus should wait for after 4.2 release (target: 4.2.1). But the Solid maintainer (Kevin) should have the last word here.

My $0.02:

This isn't release critical for people that don't continually suffer from this problem.

For those that do, the patch can't come soon enough, and they may be rather disappointed if they upgrade to 4.2 and still see it as a problem.  Disappointment leads to unhappiness.  Unhappiness leads to ranting and raving.

I'd recommend sticking it in 4.2 unless Kevin thinks that this might have adverse effects.

*** Bug 180202 has been marked as a duplicate of this bug. ***

*** Bug 180493 has been marked as a duplicate of this bug. ***

*** Bug 180820 has been marked as a duplicate of this bug. ***

*** Bug 181071 has been marked as a duplicate of this bug. ***

*** Bug 181346 has been marked as a duplicate of this bug. ***

if the patch fixes the problem, it should be in 4.2.0

*** Bug 181543 has been marked as a duplicate of this bug. ***

*** Bug 182166 has been marked as a duplicate of this bug. ***

*** Bug 182680 has been marked as a duplicate of this bug. ***

This crash is quite bad. I had plasma, konqueror, ktorrent, krunner and dolphin all die on every upgrade that hal was restarted. (They had the same backtrace as the original post)

The good news is that the patch worked wonderfully.

SVN commit 929830 by ervin:

Commit Matthias' patch which apparently creates no regression.

CCBUG: 160221


 M  +4 -3      devicemanager.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=929830

SVN commit 929831 by ervin:

Backport 929830.

BUG: 160221


 M  +4 -3      devicemanager.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=929831

*** Bug 187113 has been marked as a duplicate of this bug. ***

*** Bug 189438 has been marked as a duplicate of this bug. ***

*** Bug 176528 has been marked as a duplicate of this bug. ***

*** Bug 178845 has been marked as a duplicate of this bug. ***

Created attachment 37872


test1

Created attachment 37873


test2

Created attachment 37874


test3

Created attachment 62564 [details]
device removed assertion patch

Please consider this patch for this crash, i have kde 4.7.0 and after
switch on from suspend-to-ram i have 5 crashes on 5 components on 3 hosts.

Waiting for feedback
Best regards.

Please also reopen this bug.

Ok this patch resolved my problems with solid.

Did you apply this patch to the KDE repository? Or is this still open.

It is still open because i have no account in kde git.

Alex or Kevin,

Please can we commit this patch.  I'm hitting this assert now on two different Fedora 15 computers and causing plasma-desktop, knotify and krunner to die every few hours.

I've been running with this patch few a couple days now ok.

-Allen

(In reply to comment #70)
> Alex or Kevin,
> 
> Please can we commit this patch.  I'm hitting this assert now on two
> different Fedora 15 computers and causing plasma-desktop, knotify and
> krunner to die every few hours.
> 
> I've been running with this patch few a couple days now ok.
> 
> -Allen

That patches remove an ASSERT that makes sense and show us a bug in the library, removing it won't solve the real issue.

If you want to avoid the crash, compile libsolid without debug as you should do in production, assert won't quit the application then.

I will try to reproduce this bug and fix the real issue asap.

Can you give me some information of which kind of hardware are you plugging/unplugging? 
Does this happen without unplugging/plugging anything? do you suspend/hibernate?

Can you run in a terminal "solid-hardware listen" and save all the debug until it crashes as knotify/plasma-desktop does?

Thank s!

My patch is written according to assert done above this one, and that change was 
added to sources, so why You block this one also?

void Solid::DeviceManagerPrivate::_k_deviceAdded(const QString &udi)
{
    if (m_devicesMap.contains(udi)) {
        DevicePrivate *dev = m_devicesMap[udi].data();
 
        // Ok, this one was requested somewhere was invalid
        // and now becomes magically valid!
 
        if (dev && dev->backendObject() == 0) {
            dev->setBackendObject(createBackendObject(udi));
            Q_ASSERT(dev->backendObject()!=0);
        }
    }
 
    emit deviceAdded(udi);
}
 
     emit deviceAdded(udi);

Alex,

For me, I really think it's an automount that is going away.  I can't think of anything I purposefully am plugging/unplugging nor is this a suspend/hibernation issue.

In the meantime, I'll look for debug messages that might give you more hints.

(In reply to comment #73)
>         if (dev && dev->backendObject() == 0) {
>             dev->setBackendObject(createBackendObject(udi));
>             Q_ASSERT(dev->backendObject()!=0);
>         }
Well I'm in a hurry so maybe I'm reading this wrong but if you set the backendObject just before asserting for sure the assert won't fail but that turns the assert in invalid since it is not checking what it should check.

I slightly confused by this report.  git claims that the change people were requesting in March 2012 was already made in the repo in 2009.

Does this bug still exist?

I have no recollection of what might have fixed this bug; however, no such crash here in quite a long time.

Alex might remember.

AFIAK this one should be resolvable

Let's resolve it WORKSFORME, and if someone can reproduce it, they can re-open it.