Bug 444230
Summary: | kdebluetooth crashes in kde4 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Mike C <mike.cloaked> |
Component: | kdebluetooth | Assignee: | Gilboa Davara <gilboad> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | tuxbrewr, ville.skytta |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-04-27 12:22:42 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Mike C
2008-04-25 21:02:44 UTC
looks like a similar bug has been filed upstream. see http://bugs.kde.org/show_bug.cgi?id=150728 its for a previous version but still appears unresolved.. You may want to add your comments to that bug report as it looks like they are looking for additional info. Given the fact that upstream seems to be more-or-less dead, I'm keeping this bug open. Can you start kbluetooth under gdb and get a call stack dump? $ su -c 'yum install gdb' $ gdb /usr/bin/kbluetooth -p $(pgrep kbluetooth) (gdb) cont // ... Let it crash (gdb) thread apply all bt // Cut the call stuck. (gdb) quit - Gilboa Am away from my rawhide machine right now but will get back to it tonight and run the stack dump for you. Will report back here when done. Strange - but after installing the necessary debug files (using debuginfo-install kdebluetooth.i386 ) it did work without crashing today - but the dbg command did not work as you wrote it: [root@rawhide ~]# gdb /usr/bin/kbluetooth -p $(pgrep kbluetooth) gdb: option '-p' requires an argument Use `gdb --help' for a complete list of options. so I dropped "-p" to get dbg running and then the output during a few starts of the kbluetooth ending up with a successful pairing with the BT mouse was: (gdb) run Starting program: /usr/bin/kbluetooth [Thread debugging using libthread_db enabled] Detaching after fork from child process 3279. kbuildsycoca running... Invalid entry (missing '=') at /usr/share/applications/switchdesk.desktop:101 Program exited normally. Missing separate debuginfos, use: debuginfo-install acl.i386 attr.i386 dbus-qt.i386 dbus.i386 expat.i386 fontconfig.i386 freetype.i386 lcms.i386 libICE.i386 libSM.i386 libX11.i386 libXau.i386 libXcursor.i386 libXdmcp.i386 libXext.i386 libXfixes.i386 libXft.i386 libXi.i386 libXinerama.i386 libXrandr.i386 libXrender.i386 libart_lgpl.i386 libcap.i386 libidn.i386 libjpeg.i386 libmng.i386 libpng.i386 libutempter.i386 libxcb.i386 zlib.i386 (gdb) X Error: BadWindow (invalid Window parameter) 3 Major opcode: 20 Minor opcode: 0 Resource id: 0x3e00008 Launched ok, pid = 3365 process 3279: arguments to dbus_message_set_reply_serial() were incorrect, assertion "reply_serial != 0" failed in file dbus-message.c line 897. 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 KCrash: Application 'kbluetooth' crashing... Could not find 'drkonqi' executable. KCrash cannot reach kdeinit, launching directly. X Error: BadWindow (invalid Window parameter) 3 Major opcode: 7 Minor opcode: 0 Resource id: 0x3c00008 ICE default IO error handler doing an exit(), pid = 3362, errno = 11 However it did then continue to run and indeed I now got the BT mouse to pair up, and then connect - it is now working. I am puzzled as to why it worked today but not yesterday - though it is possible I may have started the bluetooth service (i.e. service bluetooth start) before plugging in the BT dongle today which may have been in the reverse order yesterday. However the mouse is now paired up. It is possible that the bluetooth (hcid) service needs to start in the correct order relative to plugging in the BT adapter - I will check this shortly. I don't know therefore if the output above is any use now? If not I guess if someone else can run a stack trace when it fails and put the dump here this can be debugged further. If not then I guess this bug can be closed since I now cannot re-produce the fault. I just did an additional check by stopping the bluetooth service and restarting - the mouse continues to work. Also I pulled out the dongle and plugged it back in, and it still continues to work! I guess I am stuck with a working system now - ! (In reply to comment #5) > I just did an additional check by stopping the bluetooth service and restarting > - the mouse continues to work. Also I pulled out the dongle and plugged it back > in, and it still continues to work! > > I guess I am stuck with a working system now - ! Glad to hear. Closing the bug for now. Reopen if you you hit the same bug again. - Gilboa kdebluetooth-0.2-3.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/kdebluetooth-0.2-3.fc9 kdebluetooth-0.2-3.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report. |