Bug 201896 - backtrace creation crashes whole system
Summary: backtrace creation crashes whole system
Status: RESOLVED WORKSFORME
Alias: None
Product: drkonqi
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Ubuntu Unspecified
: NOR crash
Target Milestone: ---
Assignee: Dario Andres
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-29 16:03 UTC by m.wege
Modified: 2009-08-27 22:02 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description m.wege 2009-07-29 16:03:37 UTC
Version:            (using KDE 4.2.98)
Installed from:    Ubuntu Packages

I have a reoccuring crash on Akregator. When I use Dr. Konqui to get the backtrace the system is slowing down more and more until there is a total full stop, so that I have to turn off the system. Apart from the fact that backtrace creation seems to consume lot more system ressources since KDE3 this is the only case where this happens.
Comment 1 Dario Andres 2009-07-29 16:09:43 UTC
Can you try using a GDB session on Konsole to try to get a backtrace and see if it causes the same trouble ? Thanks
Comment 2 m.wege 2009-07-29 16:37:31 UTC
How?
Comment 3 George Kiagiadakis 2009-07-29 17:00:14 UTC
How much RAM and swap do you have? This sounds like gdb runs out of memory and starts writing on the swap, which causes thrashing... This can't really stop the system though, although you may notice the GUI freezing for a long time (let's say 10 minutes or so...). In the end it will either display you the result or the kernel will kill the process that consumes the most memory (here, probably gdb) and everything will be back to normal.

Now, to test only with gdb, do the following:
Edit your ~/.kde/share/config/drkonqirc (create it if necessary) and add two lines saying:

[drkonqi]
ShowDebugButton=true

Now when drkonqi opens when this crash occurs, you will have a button named "Debug" with a submenu choice to "Debug in gdb". Click on that and leave drkonqi in the background. gdb will now open in a konsole (just make sure you have no other konsole windows open before clicking this button, because there is currently a bug with that). When gdb is up and running, type "thread apply all bt" and hit enter in the gdb prompt. This will do the same thing that drkonqi does behind the scenes. If this also takes too much time and freezes the system, the problem is in gdb and not in drkonqi, but I think it is actually a normal behavior if you do not have enough RAM and swap.
Comment 4 m.wege 2009-07-29 17:05:20 UTC
I have 2GB Ram and 3.5 Swap. I will try and see what happens.
Comment 5 m.wege 2009-07-29 17:08:04 UTC
I have 2GB Ram and 3.5 Swap. I will try and see what happens.
Comment 6 m.wege 2009-07-30 09:29:38 UTC
I have management to retrieve a backtrace with your described method without having a crash. See bug: https://bugs.kde.org/show_bug.cgi?id=201976
Comment 7 George Kiagiadakis 2009-07-30 10:59:44 UTC
Hm, this is weird... This is a lot of ram, it should work. I'll check a bit more the memory usage of drkonqi itself, but I'm not sure that will lead anywhere...
Comment 8 Dario Andres 2009-08-26 16:03:19 UTC
- Is this still happening on 4.3.0 ?
Comment 9 m.wege 2009-08-27 22:02:42 UTC
I did not have that crash anymore. So I can not tell if the underlying problem is gone. But I guess it can be closed and if it reoccurs reopened again.