Version: 3.5.6 (using KDE KDE 3.5.5) Installed from: Gentoo Packages Compiler: gcc (GCC) 4.1.1 (Gentoo 4.1.1-r3) (C/XX)FLAGS="-march=athlon64 -O2 -pipe -ggdb" OS: Linux Whenever (almost) a CD/DVD is mounted (insert, click open in new folder in Dialog for instance) and the physical eject button is pushed kded crashes. Backtrace: Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 47207097333104 (LWP 5463)] [KCrash handler] #5 0x00002aef422397b5 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #6 0x00002aef4223aa4e in *__GI_abort () at abort.c:88 #7 0x00002aef434f4b85 in _dbus_abort () at dbus-sysdeps.c:84 #8 0x00002aef434f1325 in _dbus_warn_check_failed ( format=0x2aef434fbea0 "arguments to %s() were incorrect, assertion \"%s\" failed in file %s line %d.\nThis is normally a bug in some application using the D-Bus library.\n") at dbus-internals.c:283 #9 0x00002aef434e7297 in dbus_message_new_method_call ( destination=0x2aef432baa3a "org.freedesktop.Hal", path=0x79e260 "/org/kde/mediamanager/fstab/dx:mntbackupmntbackup", interface=0x2aef432baa1f "org.freedesktop.Hal.Device", method=0x2aef432bac4c "GetPropertyString") at dbus-message.c:1074 #10 0x00002aef432b982b in libhal_device_get_property_string (ctx=0x5c2910, udi=0x1557 <Address 0x1557 out of bounds>, key=0x2aef430a3878 "block.storage_device", error=0x7fff6c9a0060) at libhal.c:1123 #11 0x00002aef43094c27 in libhal_device_get_property_QString (ctx=0x5c2910, udi=0x79e260 "/org/kde/mediamanager/fstab/dx:mntbackupmntbackup", key=0x2aef430a3878 "block.storage_device") at halbackend.cpp:50 #12 0x00002aef43099b4c in HALBackend::DeviceCondition (this=0x5f97f0, udi=0x5ff2d8 "/org/freedesktop/Hal/devices/storage_model__NEC_DVD_RW_ND_3540A", condition=<value optimized out>) at halbackend.cpp:321 #13 0x00002aef432b8347 in filter_func (connection=<value optimized out>, message=0x5f9890, user_data=<value optimized out>) at libhal.c:711 #14 0x00002aef434dca7f in dbus_connection_dispatch (connection=0x5fce10) at dbus-connection.c:4267 #15 0x00002aef433c83a0 in DBusQt::Connection::dispatchRead (this=0x5d1fa0) at ./connection.cpp:119 #16 0x00002aef433c8abc in DBusQt::Connection::qt_invoke (this=0x5d1fa0, _id=8, _o=0x7fff6c9a0510) at ./connection.moc:112 #17 0x00002aef3fc55a3c in QObject::activate_signal (this=0x5fdf20, clist=<value optimized out>, o=0x7fff6c9a0510) at kernel/qobject.cpp:2356 #18 0x00002aef3fc566e3 in QObject::activate_signal (this=0x1557, signal=<value optimized out>) at kernel/qobject.cpp:2325 #19 0x00002aef433c90f6 in DBusQt::Internal::Integrator::slotRead ( this=0x5fdf20, fd=<value optimized out>) at ./integrator.cpp:169 #20 0x00002aef433c915e in DBusQt::Internal::Integrator::qt_invoke ( this=0x5fdf20, _id=2, _o=0x7fff6c9a0620) at ./integrator.moc:233 #21 0x00002aef3fc55a3c in QObject::activate_signal (this=0x600c10, clist=<value optimized out>, o=0x7fff6c9a0620) at kernel/qobject.cpp:2356 #22 0x00002aef3fc56615 in QObject::activate_signal (this=0x600c10, signal=<value optimized out>, param=<value optimized out>) at kernel/qobject.cpp:2449 #23 0x00002aef3fc7017b in QSocketNotifier::event (this=0x600c10, e=0x7fff6c9a0910) at kernel/qsocketnotifier.cpp:258 #24 0x00002aef3fbff8b5 in QApplication::internalNotify ( this=<value optimized out>, receiver=0x600c10, e=0x7fff6c9a0910) at kernel/qapplication.cpp:2635 #25 0x00002aef3fc004b7 in QApplication::notify (this=0x7fff6c9a0ba0, receiver=0x600c10, e=0x7fff6c9a0910) at kernel/qapplication.cpp:2358 #26 0x00002aef3f044850 in KApplication::notify (this=0x7fff6c9a0ba0, receiver=0x600c10, event=0x7fff6c9a0910) at kapplication.cpp:550 #27 0x00002aef3fbf5abb in QEventLoop::activateSocketNotifiers (this=0x5b7da0) at kernel/qapplication.h:496 #28 0x00002aef3fbb6d13 in QEventLoop::processEvents (this=0x5b7da0, flags=<value optimized out>) at kernel/qeventloop_x11.cpp:383 #29 0x00002aef3fc14092 in QEventLoop::enterLoop (this=0x1557) at kernel/qeventloop.cpp:198 #30 0x00002aef3fc13f42 in QEventLoop::exec (this=0x1557) at kernel/qeventloop.cpp:145 #31 0x00002aef428ca2e4 in kdemain (argc=<value optimized out>, argv=<value optimized out>) at kded.cpp:960 #32 0x0000000000406f76 in launch (argc=2, _name=0x4097af "kded", args=0x4097d2 "", cwd=0x0, envc=0, envs=0x0, reset_env=false, tty=0x0, avoid_loops=false, startup_id_str=0x40972a "0") at kinit.cpp:673 #33 0x0000000000408bc5 in main (argc=5, argv=0x7fff6c9a1618, envp=0x7fff6c9a1648) at kinit.cpp:1856 #34 0x00002aef42227394 in __libc_start_main (main=0x408500 <main>, argc=5, ubp_av=0x7fff6c9a1618, init=<value optimized out>, fini=<value optimized out>, rtld_fini=<value optimized out>, stack_end=0x7fff6c9a1608) at libc-start.c:238 #35 0x00000000004045f9 in _start () Current language: auto; currently c
Same behaviour with Ubuntu Edgy and KDE 3.5.6.
Problem appears here too: Gentoo KDE-3.5.6 hal-0.5.9 dbus-1.0.2 Kernel: 2.6.19-suspend2 The backtrace seems to be unusable here although it's a debug build, but valgrind looks better: elias@nx9420 ~ $ valgrind --tool=memcheck kded ==28051== Memcheck, a memory error detector. ==28051== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==28051== Using LibVEX rev 1658, a library for dynamic binary translation. ==28051== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==28051== Using valgrind-3.2.1, a dynamic binary instrumentation framework. ==28051== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==28051== For more details, rerun with: -v ==28051== ==28052== Syscall param write(buf) points to uninitialised byte(s) ==28052== at 0x54C4C83: __write_nocancel (in /lib/libpthread-2.5.so) ==28052== by 0x53EE7C7: (within /usr/lib/libX11.so.6.2.0) ==28052== Address 0x582BF58 is 184 bytes inside a block of size 16,384 alloc'd ==28052== at 0x4020753: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==28052== by 0x53D4FA5: XOpenDisplay (in /usr/lib/libX11.so.6.2.0) ==28051== ==28051== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 1) ==28051== malloc/free: in use at exit: 49,843 bytes in 2,467 blocks. ==28051== malloc/free: 16,471 allocs, 14,004 frees, 316,438 bytes allocated. ==28051== For counts of detected errors, rerun with: -v ==28051== searching for pointers to 2,467 not-freed blocks. ==28051== checked 774,256 bytes. ==28051== ==28051== LEAK SUMMARY: ==28051== definitely lost: 0 bytes in 0 blocks. ==28051== possibly lost: 0 bytes in 0 blocks. ==28051== still reachable: 49,843 bytes in 2,467 blocks. ==28051== suppressed: 0 bytes in 0 blocks. ==28051== Reachable blocks (those to which a pointer was found) are not shown. ==28051== To see them, rerun with: --show-reachable=yes elias@nx9420 ~ $ ==28055== ==28055== ERROR SUMMARY: 6 errors from 1 contexts (suppressed: 7 from 1) ==28055== malloc/free: in use at exit: 900,104 bytes in 14,642 blocks. ==28055== malloc/free: 154,525 allocs, 139,883 frees, 7,441,019 bytes allocated. ==28055== For counts of detected errors, rerun with: -v ==28055== searching for pointers to 14,642 not-freed blocks. ==28055== checked 1,604,344 bytes. ==28055== ==28055== LEAK SUMMARY: ==28055== definitely lost: 6,372 bytes in 164 blocks. ==28055== possibly lost: 68 bytes in 1 blocks. ==28055== still reachable: 893,664 bytes in 14,477 blocks. ==28055== suppressed: 0 bytes in 0 blocks. ==28055== Use --leak-check=full to see details of leaked memory. ==28052== ==28052== Syscall param writev(vector[...]) points to uninitialised byte(s) ==28052== at 0x569442E: (within /lib/libc-2.5.so) ==28052== by 0x53EE761: (within /usr/lib/libX11.so.6.2.0) ==28052== Address 0x582BF9C is 252 bytes inside a block of size 16,384 alloc'd ==28052== at 0x4020753: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==28052== by 0x53D4FA5: XOpenDisplay (in /usr/lib/libX11.so.6.2.0) ==28052== Warning: noted but unhandled ioctl 0x5327 with no size/direction hints ==28052== This could cause spurious value errors to appear. ==28052== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==28052== Warning: noted but unhandled ioctl 0x5327 with no size/direction hints ==28052== This could cause spurious value errors to appear. ==28052== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==28052== Warning: noted but unhandled ioctl 0x5327 with no size/direction hints ==28052== This could cause spurious value errors to appear. ==28052== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. process 28052: arguments to dbus_message_new_method_call() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file dbus-message.c line 1074. This is normally a bug in some application using the D-Bus library. /usr/lib/libdbus-1.so.3 [0x672d8ee] Last DCOP call before KDED crash was from application 'kded' to object 'KDirNotify-4', function 'FilesChanged(KURL::List)'. KCrash: Application 'kded' crashing... ==28052== ==28052== ERROR SUMMARY: 23 errors from 2 contexts (suppressed: 7 from 1) ==28052== malloc/free: in use at exit: 1,818,914 bytes in 39,035 blocks. ==28052== malloc/free: 660,318 allocs, 621,283 frees, 19,018,297 bytes allocated. ==28052== For counts of detected errors, rerun with: -v ==28052== searching for pointers to 39,035 not-freed blocks. ==28052== checked 2,468,500 bytes. ==28052== ==28052== LEAK SUMMARY: ==28052== definitely lost: 47,936 bytes in 361 blocks. ==28052== possibly lost: 68 bytes in 1 blocks. ==28052== still reachable: 1,770,910 bytes in 38,673 blocks. ==28052== suppressed: 0 bytes in 0 blocks. ==28052== Use --leak-check=full to see details of leaked memory.
Tried to reproduce it several times. Everytime kded crashed, it was one of this both reasons: process 16426: arguments to dbus_message_new_method_call() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file dbus-message.c line 1074. This is normally a bug in some application using the D-Bus library. /usr/lib/libdbus-1.so.3 [0x672d8ee] Last DCOP call before KDED crash was from application 'DCOPServer' to object '', function 'applicationRemoved(QCString)'. KCrash: Application 'kded' crashing... process 17530: arguments to dbus_message_new_method_call() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file dbus-message.c line 1074. This is normally a bug in some application using the D-Bus library. /usr/lib/libdbus-1.so.3 [0x672d8ee] Last DCOP call before KDED crash was from application 'kded' to object 'KDirNotify-4', function 'FilesChanged(KURL::List)'. KCrash: Application 'kded' crashing... Sadly I don't know enough about getting more details using dbg. Maybe somebody can reproduce this or tell me, how to provide more details. Thank you! Elias P.
Earlier, I had a similar mistake: http://bugs.kde.org/show_bug.cgi?id=143070 But in now mistake has disappeared. And it seemed to me, that this mistake was from for lines in a file /etc/fstab: =============================== //user@host/C$ /mount/point smbfs rw,noauto,-I192.168.2.5,-Ekoi8-r:cp866,-f666,-N 0 0 =============================== But I can and be mistaken, as it does not repeat any more. Probably, the mistake has ceased appears from for that that in FreeBSD, changes in a file "/etc/fstab" more are not processed. $ pkg_info -E hal\* dbus\* kde-3\* ; uname -rms dbus-1.0.2_1 dbus-glib-0.73 dbus-qt3-0.70 hal-0.5.8.20070403 hal-device-manager-0.5.8.20070403 kde-3.5.6 FreeBSD 6.2-STABLE i386
See bug 151038 ( https://bugs.kde.org/show_bug.cgi?id=151038 ). Naga, your HAL path is "dx:mntbackupmntbackup". It looks like you have a colon ':' somewhere in your fstab. Remove that colon, and your problem might go away. For the other affected users: Watch out for characters in the first and second column in your "/etc/fstab" file which do not match "[A-Za-z0-9_]". Try again with these characters removed.
Well I do have a ":" in my fstab since I mount some dirs using nfs. ie: host:/path/to/dir syntax.
I can consistently recreate the problem with KDE 3.5.7 (openSuse 10.3) I can confirm that removing any entries in /etc/fstab which do not match "[A-Za-z0-9_]" eleminates the crash. But that workaround is not usable because my /etc/fstab contains both suse-generated lines like: /dev/disk/by-id/scsi-SATA_SanDisk_SDCFX3-_103401D2697X4431-part6 swap ... and also NFS mounts like: isjfs-i1:/home /mnt/isjfs_home ...
Recreated a problem on openSUSE 10.3 Absolutely right, the necessary conditions (as for me) are: 1. you need to burn cd/dvd with k3b once 2. you need to have network paths in your /etc/fstab Removing network paths is a TEMPORARY solution. Let's vote for this bug)
*** Bug 150804 has been marked as a duplicate of this bug. ***
Already fixed.
*** Bug 151038 has been marked as a duplicate of this bug. ***
*** Bug 143070 has been marked as a duplicate of this bug. ***
This happens for me EVERY time I log out. I use startkde to start my kde session: startkde: Starting up... kbuildsycoca running... Desktop Layout OK No running windows found QApplication::postEvent: Unexpected null receiver startkde: Shutting down... klauncher: Exiting on signal 1 kded: ERROR: : couldn't create slave : No se puede dialogar con klauncher process 19965: arguments to dbus_message_new_method_call() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file dbus-message.c line 1074. This is normally a bug in some application using the D-Bus library. D-Bus not built with -rdynamic so unable to print a backtrace Last DCOP call before KDED crash was from application 'DCOPServer' to object '', function 'applicationRemoved(QCString)'. KCrash: Application 'kded' crashing... Warning: connect() failed: : No existe el fichero o el directorio KCrash cannot reach kdeinit, launching directly. startkde: Running shutdown scripts... startkde: Done. It takes like 10 seconds or so to exit kde, and then it exits with this error.
I saw Lubos's comment http://bugs.kde.org/show_bug.cgi?id=140668#c10 about the fact that this bug is now fixed, but I am wondering which version of KDE fixes the problem. In fact I am using KDE 3.5.8 and I run into the problem reported here. Maybe it was only fixed in KDE 3.5.9 ? More precisely, I am looking for the revision of the fix (somewhere in http://websvn.kde.org/). Is there a way to find it or could someone provide the information ?