| Summary: | [Regression] Kdict applet crashes with no usable backtrace | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Darrell <darrella> |
| Component: | tdenetwork | Assignee: | Michele Calgaro <michele.calgaro> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bnelson, bugwatch, darrella, gamrat.kristopher, james, kb9vqf, marco257, michele.calgaro, slavek.banko |
| Priority: | P5 | ||
| Version: | R14.0.0 [Trinity] | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Bug Depends on: | |||
| Bug Blocks: | 2468 | ||
| Attachments: |
strace of kdict of trinity-2014-02-10 GIT build
tde-cmake.build.sh (builds cmake-aware TDE components) |
||
|
Description
Darrell
2013-12-01 17:22:35 CST
Might be related: http://dbinfo.com no longer exists. Regardless, the applet should not crash. http://define(.com) remain in use. And oh, kdict applet is an online tool. Hence, tdenetwork. Created attachment 1928 [details]
strace of kdict of trinity-2014-02-10 GIT build
Every month of so, I build from GIT sources. Most recently from 2014-02-10 and now the behavior has changed on kdict. Running from the command line, here's what happens: /opt/trinity/bin/kdict ERROR: KUniqueApplication: Pipe closed unexpectedly. Two other apps in tdenework (kget and krdc) were tested and work properly. I can do whatever is desired to help solve this since I'm fairly competent with cmake, gcc, gdb and the development tools. A build of the original kde-3.5.10 does not have this problem with kdict. In tde/main/tdenetwork/kdict, this timestamp is present: CMakeLists.txt:# (C) 2010-2011 Serghei Amelian Interesting. I can run kdict directly (terminal or Alt+F2) and the app starts fine with no messages. I'm using a git build from about three days ago. Either directly or as an applet, kdict still crashes with no useful backtrace. Created attachment 1929 [details]
tde-cmake.build.sh (builds cmake-aware TDE components)
I also have a debugging versipn of this script and can provide it it desired.
(In reply to comment #4) > Interesting. I can run kdict directly (terminal or Alt+F2) and the app starts > fine with no messages. I'm using a git build from about three days ago. > > Either directly or as an applet, kdict still crashes with no useful backtrace. It looks like we're the two wordsmiths most interested in kdict, one of the applets that's still unmatched in KDE4 (along with kweatherservice). Are you doing s 32 or 64 bit build? I'm looking for every scrap of evidence I can find that may explain this. In the interest of transparency, attached is my tde-cmake.build.sh script that I use for all the cmake-aware Trinity projects. To repeat for emphasis, every single aspect of Trinity from the GIT pull of 2014-02-10 works flawlessly except for the nagging kdict applet, whether from the panel or standalone from the command line. >Are you doing s 32 or 64 bit build?
32 bit.
(In reply to comment #7) > >Are you doing s 32 or 64 bit build? > 32 bit. I think we're having a conversation just among ourselves but here goes anyway. And this would all be mostly moot if KDE4 had a panel applet anywhere nearly as nice as good old "kdict". I've become quite accustomed to KDE4, especially because of Activities but when I fire up KDE3, I pine for an applet that was as good the one from the olden days. So...it matters not with 32 or 64 bits. If any of the Trinity folk drop by, maybe that will be of some help. I'll also add that "http://dbinfo" is present in the original KDE-3.5.10 source for "dict.cpp". And as a further data point, I have the TDE/Fedora-17.x86_64 package on VirtualBox and kdict works fine there. It's bundled into trinity-kdict-3.5.13.2-3.fc17.opt.x86_64. That's back before the time when "tde" in library file names wasn't used, predating the R14.0 visible version. In may ample :) free time, it might be interesting to rollback the GIT revisions in tdenetwork. Of course with the library name change and the headers all different with QT vs. TQT, it won't be trivial. I confirm kdict works in 3.5.13.2. I am tagging this report as a regression. I have a collection of git package sets. Using a package set from January 2013, kdict crashed. I saw this output: TQEventLoop: this object can only be used in threads constructed via TQThread. I believe this package set is older than when the kcrash improvements were made, which would explain why kcrash was not invoked. As the message indicates a threading problem, I rebuilt tqt3 without -glibmainloop to build with the internal event loop. That proved nothing, but as I ran kdict from a terminal, the resulting error message was interesting: TQSocketNotifier: invalid socket 10 and type 'Read', disabling... TQSocketNotifier: invalid socket 5 and type 'Read', disabling... kdict: Fatal IO error: client killed Seems the problem could be threading or the TQt3 socket notifier. We have two problems to resolve to close this report: 1) resolve the crash and 2) ensure kdict creates usable backtraces. Sigh... /opt/trinity/bin/kdict Dictionary 0.6 on Arch Linux, Trinity R14.0.0 - Development - 32bit, running in KDE4. Cut and paste fails from the "About Dictionary" window, but that is a separate bug. "Dictionary" starts ok, but seg faults after entering a word and selecting "define" or pressing "enter". If "enter" is pressed or "define" is selected with <nothing> entered into the search box, then there is no SIGSEGV. I also remember Dictionary working without problem in 13.5. "strace" doesn't seem to enlighten. Sorry I'm not being more helpful. Running from the command line gives: [kcrash] TDECrash: crashing... crashRecursionCounter = 2 [kcrash] TDECrash: Application Name = kdict path = <unknown> pid = 30253 TQSocketNotifier: invalid socket 10 and type 'Read', disabling... TQSocketNotifier: invalid socket 5 and type 'Read', disabling... kdict: Fatal IO error: client killed zone still contained 7 blocks Generally, the menu functions work normally, except for the "Server" functions. One time - I think it was from "Server/Server Information" - and I have not been able to reproduce this except sporadically - running from the command line, there was: [kcrash] TDECrash: crashing... crashRecursionCounter = 2 [kcrash] TDECrash: Application Name = kdict path = <unknown> pid = 30345 TQSocketNotifier: invalid socket 10 and type 'Read', disabling... TQSocketNotifier: invalid socket 8 and type 'Read', disabling... TQSocketNotifier: invalid socket 5 and type 'Read', disabling... [xcb] Unknown sequence number while processing queue [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that. kdict: xcb_io.c:274: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed. [kcrash] Unable to start Dr. Konqi That seems consistent with the speculation about a threading problem. Maybe "XInitThreads" gets bypassed along some code path? Where is Christian Gebauer, gebauer@kde.org, the Maintainer? Are you seeing this? James I have the same problem as that described by Darrell. I have an amd_64 machine and run Ubuntu Precise with TDE R14. I do not have that problem on my other machine, a 32-bit system with Ubuntu Ocelot TDE R3.5.13.2 Marco Output from console ; [kcrash] TDECrash: Application 'kdict' crashing... [KDE-ICE error] ICE default IO error handler doing an exit(), pid=15943, errno=9 (In reply to Marco from comment #11) > I have the same problem as that described by Darrell. I have an amd_64 > machine and run Ubuntu Precise with TDE R14. > > I do not have that problem on my other machine, a 32-bit system with Ubuntu > Ocelot TDE R3.5.13.2 > > Marco > > Output from console ; > > [kcrash] TDECrash: Application 'kdict' crashing... > [KDE-ICE error] ICE default IO error handler doing an exit(), pid=15943, > errno=9 Forgot to add output from .xsession-errors : X Error: BadWindow (invalid Window parameter) 3 Major opcode: 19 Minor opcode: 0 Resource id: 0x4c00006 kdesktop: WARNING: failed to obtain ELF icon: ELF resource section not found kdesktop: WARNING: failed to obtain ELF icon: ELF resource section not found [kcrash] TDECrash: Application 'kdict' crashing... kdict: Fatal IO error: client killed X Error: BadWindow (invalid Window parameter) 3 Major opcode: 19 Minor opcode: 0 Resource id: 0x4c00011 This crash report might be related: https://crashreport.trinitydesktop.org/?action=detail&crashid=TDECRSH-c2afd01-24431ae-a0194b0-4481f6d-ba889da-0c48aa0-8442c2a It looks like threading in kdict is broken. I can confirm that this bug still present in R14.0.0 stable -- KDict will load, but immediately upon trying to look up a word (i.e. after the word is typed, when I hit enter/click the button), it crashes and triggers the TDE Crash Handler. Neither gdb nor the TDE Crash Manager can obtain a backtrace, despite having literally every debugging package for TDE and Xorg installed (yes, I know, that's overkill ;-) ). All I can get is the following info from ~/.xsession-errors : [kcrash] TDECrash: Application 'kdict' crashing... kdict: Fatal IO error: client killed TQThreadInstance::start: Setting thread storage to 0x7f491c002190 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 19 Minor opcode: 0 Resource id: 0x4000013 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 19 Minor opcode: 0 Resource id: 0x400000b X Error: BadWindow (invalid Window parameter) 3 Major opcode: 19 Minor opcode: 0 Resource id: 0x4000008 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 19 Minor opcode: 0 Resource id: 0x4000008 > http://dbinfo.com no longer exists
Could anyone provide a server and port number that can be used for testing and debugging this problem? Thanks
>> http://dbinfo.com no longer exists
> Could anyone provide a server and port number that can be used for testing and
> debugging this problem? Thank
dict.org seems to do the job.
I will see what I can do for this bug.
Working on it, although the nature of the problem may require some time. I can now proceed past the "kdict: Fatal IO error: client killed" error message, but kdict is still not working correctly. The problem is caused by the fact that KDict uses signals and slots in pthread-created threads, which are not compatible with qt3/tqt3 thread support infrastracture (i.e. TQThread::currentThread() returns 0 instead of a thread handle). I now have a working kdict and kdict applet in my system. I will push the required patches as soon as it is allowed by the R14.0.1 building process. Fixed in commit 8942bd9 (master) and c016e48 (r14.0.x) Also related to this bug are the following commits: - tqt3: caab7b3 (master) and a6e1bf7 (r14.0.x) - qt3 : dad70b4 (master) and 8eefba8 (r14.0.x) |