| Summary: | The crash manager causing high cpu usage | ||
|---|---|---|---|
| Product: | [Applications] drkonqi | Reporter: | Dan <dan76> |
| Component: | general | Assignee: | George Kiagiadakis <mail> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | andresbajotierra, mail, tiposchi, zahl |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Valgrind output (kopete) | ||
|
Description
Dan
2008-11-17 01:50:07 UTC
Yes. Generating backtraces is high on CPU usage. Or do you mean that it stays "high CPU", even the backtrace is generated? That should be "even *after* the backtrace is generated"... Also, what svn version are you using? And what distro? Hi, yes, *even* after backtrace was generated. While the kde crash handler window is opened, there's a high cpu usage. kdelibs: 885337 kdebase: 885337 Distribution: Linux from scratch Well, that shouldn't happen. Is there anything in your distro's bugtracker on this? I can't confirm it, and neither can someone who is running x86_64 with a recent trunk. I guess my trunk is slightly older than yours. It's probably some kind of library error or something. Actually, if you run "top", what does it say is taking up all the cpu? Sometimes it happens that the application that crashed takes 100% cpu usage while drkonqui is open, even if gdb has stopped generating the backtrace. It has happened to me 1-2 times but it's not reproducable. A. Spehr, here's the top output (as you can see, the crashed application -- kopete -- is using 100% of cpu. And it keeps this way until I close the crash handler window):
top - 11:00:44 up 1:17, 4 users, load average: 1.50, 0.87, 0.79
Tasks: 128 total, 3 running, 125 sleeping, 0 stopped, 0 zombie
Cpu(s): 46.2%us, 3.8%sy, 0.0%ni, 49.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 2059932k total, 1422008k used, 637924k free, 28988k buffers
Swap: 136512k total, 136508k used, 4k free, 478928k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22411 fraga 20 0 428m 68m 22m S 100 3.4 1:09.75 kopete
2848 root 20 0 405m 178m 3284 S 0 8.9 1:35.72 X
1 root 20 0 3732 528 496 S 0 0.0 0:00.19 init
2 root 15 -5 0 0 0 S 0 0.0 0:00.00 kthreadd
3 root RT -5 0 0 0 S 0 0.0 0:00.00 migration/0
4 root 15 -5 0 0 0 S 0 0.0 0:00.01 ksoftirqd/0
5 root RT -5 0 0 0 S 0 0.0 0:00.02 migration/1
6 root 15 -5 0 0 0 S 0 0.0 0:00.02 ksoftirqd/1
And this is 100% reproducible for you? Can you run it under valgrind and then crash? And see if you get useful output? Created attachment 28756 [details]
Valgrind output (kopete)
Hi Spehr, I ran Kopete with valgrind and the output is attached. But I can't even use the Kopete app. It crashed when it was connecting... so probably it is not usefull... Would it be better to use strace instead? I can actually reproduce this reliably now.... the process that calls drkonqui seems to hang around kdeui/utils/kcrash.cpp:412 (this is intended) and consume 100% cpu usage while it is there (this is not intended). Tested with today's trunk (r8900xx). This is very tricky... I just crashed plasma and it did not eat any cpu while the crash handler was open, although it was looping around the same loop at kcrash.cpp:412. This bug only seems to happen with kopete! My guess is that kopete uses some low level unix stuff that makes that sleep(1); call in kcrash.cpp:412 not to work... I think I now understand the reason why this happens. The crash handler only runs in one thread and makes only this thread sleep. All the other threads continue running somehow, so this causes a lot of cpu usage. I'll try to investigate more and fix it. SVN commit 932785 by gkiagia: Stop the crashed process while it's not being debugged. This will avoid having high cpu usage by the other threads of that process. CCBUG: 175362 M +14 -3 backtracegenerator.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=932785 (In reply to comment #14) > SVN commit 932785 by gkiagia: > > Stop the crashed process while it's not being debugged. > This will avoid having high cpu usage by the other threads of that process. Ok, this seems to solve the problem. Thanks. I reopen this bug as I'd like to keep it as a reminder of the fixes that have been commited to /branches/work/drkonqi-newdialog but not in trunk. This bug will be closed when this code is moved to trunk. *** Bug 188531 has been marked as a duplicate of this bug. *** The new DrKonqi implementation was moved to 4.3trunk. |