| Summary: | krunner will sometimes crash silently (i.e., without any backtrace) | ||
|---|---|---|---|
| Product: | [Plasma] krunner | Reporter: | doc.evans |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | crash | CC: | andresbajotierra, angel_blue_co2004, annma, wilderkde |
| Priority: | NOR | Keywords: | investigated, triaged |
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
doc.evans
2009-03-13 18:13:44 UTC
May you read http://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_useful_crash_reports and try to post a complete backtrace here? Thanks :) I already have all the Kubuntu debugging packages (that I know of) installed. If you want to give me some libraries by name, I can check that I have the debug version installed. I'm not sure exactly what you're trying to tell me by pointing me to that URL. That page says: "Now it's time to crash your application. The KDE Crash Dialog should appear right after the crash, which shows the Backtrace tab." But that's not what is happening The point is that this is *silent*. The crash handler is never invoked. So one never sees any backtrace. To try to make it clearer: 1. User starts to type a word into krunner. 2. krunner simply disappears. 3. From that point on, pressing the key combination no bring up krunner no longer works. That page is intended as a common way to help people to get better backtraces.. However I suppose it's a bit outdated ( there's no backtrace tab at KDE4 ) Anyways... As you aren't getting the DrKonqi dialog we need to force GDB... So you need to do the following: - Open a Konsole window - Type "kquitapp krunner" and press Return This will close the KRunner current instance - Type "gdb krunner" and press Return - Type "run --nofork" and press Return This will start KRunner with debugging symbols on. - Now, try to use and crash KRunner When KRunner crashes... - Go back to the Konsole/GDB window - Type "thread apply all backtrace" and press Return to get a backtrace There should be output to that command.. otherwise.. it didn't crashed, but it closed (that would be weird ) Thanks OK. There is a problem, though (isn't there always?) It is (unfortunately) so trivially easy to crash krunner that I don't think I can tell whether a particular crash is a "crash that would have produced a backtrace" or a "crash that would have been silent". So I can produce tons of backtraces for you, but I don't know how to know whether they apply to this particular bug report. Since I don't want to contaminate this report by including backtraces associated with other crash-inducing bugs, is there some way you can suggest for me to know whether, when I produce a crash under gdb, it would have been a "silent" crash if I had been running krunner normally? (Thinking about this with 20/20 hindsight, perhaps this bug report should have been something like "krunner crashes without invoking crash handler".) Running through gdb will get you a backtrace for those silent crashes anyway, even if you do not know how to reproduce. Just always run krunner through gdb and when you have a crash get the output from the konsole as explained above. I think even through gdb you can have the krash window popping. Also check against bugs.kde.org if it was reported using the match in comment line with one of the crash first lines. Also you should update your KDE version to 4.2.1, 4.2.0 is now old by our development standards. It is also possible that the "crash without backtrace" is not even a crash, but a deadlock. We solved a bad deadlock recently (after 4.2.1), so it would be very good if you upgrade at least to the svn branch 4.2. Either if you cannot, could you please run krunner in gdb and when it "crashes" (or rather "hangs") go back to the gdb session, type Ctrl-C to interrupt and then obtain a backtrace as explained in comment #3 That would be very useful. -- J Bug #186829 seems to be related to this bug, both actually refer to the same couple of issues, I propose to keep this report for "crash without backtrace" and the other report for "crash with backtrace". Thanks to the reporter for the suggestion. As for this bug, can you reproduce on 4.2.1? 4.2.x? It used to be trivially easy to crash krunner for me as well, but now somehow it's kinda harder, so your help would be really appreciated. --J I think I can add to this from KDE 4.3 beta 2: Krunner would crash silently. Following the instructions here in this bug I traced it down to the fsrunner runner. > Following the instructions here in this bug I traced it down to the fsrunner
> runner.
The fsrunner runner is not mantained by kde, it is an unofficial add-on
@doc: can you still reproduce using a recent version of kde / qt?
Waiting for feedback Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |