Bug 201896

Summary:	backtrace creation crashes whole system
Product:	[Applications] drkonqi	Reporter:	m.wege
Component:	general	Assignee:	Dario Andres <andresbajotierra>
Status:	RESOLVED WORKSFORME
Severity:	crash	CC:	mail
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Ubuntu
OS:	Unspecified
Latest Commit:		Version Fixed In:
Sentry Crash Report:

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.