| Summary: | 100% CPU usage | ||
|---|---|---|---|
| Product: | [Unmaintained] rekonq | Reporter: | Jean-Marie Favreau <jm.trivial> |
| Component: | general | Assignee: | Andrea Diamantini <adjam7> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | benjamin.poulain, pano_90 |
| Priority: | NOR | ||
| Version: | 0.5.0 | ||
| Target Milestone: | --- | ||
| Platform: | Debian unstable | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
result of "strace rekonq"
opreport result valgrind logs (1) Valgrind logs (2) |
||
I tried the following approach on the "broken" account: - start my kde session - "mv .kde/share/ .kde/shareold" - start rekonq The problem still appeared. I tried also to change the them (from qtcurves to another one), and the problem is still present. I tried to remove the /var/tmp/kdecache-user directory, but the problem still appears. Could you try to get a profile with oprofile on your rekonq when it is stuck at 100% CPU? It could help to understand where Rekonq is stuck. I had similar problems once and the CPU time was spent in the event loop. It was a bug of adobe flash triggering way too many timers (even though no page with flash was open). As you suggested, I used oprofile in order to locate the cpu usage. You'll found attached the result of opreport. It seems that the loop is located into libQtCore.so.4.6.3. I used kcachegrind in order to explore the corresponding trace, and it seems that 81% of the CPU time is dedicated to QEventLoop::processEvents(). Notice that I'm using gnash (not the adobe plugin). Another strange thing is that using "sudo -u jm rekonq" on my broken account makes rekonq working fine. Created attachment 49561 [details]
opreport result
Your trace clearly shows something is overloading the event loop. You should debug which object is sending/receiving the events and you should have the cause of the problem. Callgrind might help here. To run WebKit with callgrind, you need to add --smc-check=all: valgrind --tool=callgrind --smc-check=all ./rekonq -graphicssystem raster The option "--smc-check=all" is needed because of the JIT reusing pages for code. I tried valgrind, and I've seen that gtk_rc_reparse_all_for_settings was one of the function that was using the main part of the CPU time. I removed gnash from my system, in order to see if it was the reason, but apparently, not. I attached the callgrind logs. I don't understand why the "sudo -u jm rekonq" is working, since rekonq (directly using the jm account) is not working fine. Created attachment 49606 [details]
valgrind logs (1)
Created attachment 49607 [details]
Valgrind logs (2)
All the time is spend because of gtk-qt-engine (libqt4engine) choking the CPU.
The callgrind profile does not have the debug symbols for it so it is hard to say what is wrong in there. It is probably a problem of configuration making the engine enter an infinite loop through the event loop.
> I don't understand why the "sudo -u jm rekonq" is working
The environment variables could be different?
I suggest to close this particular bug report as invalid and to open a new bug report on the bug tracker of gtk-qt-engine.
@ Benjamin: Thanks for the help on this :-) |
Created attachment 49149 [details] result of "strace rekonq" Version: 0.5.0 (using KDE 4.4.4) OS: Linux I previously used rekonq 0.4.0 without problem on my debian sid. After the last upgrade, when I started rekonq, it takes 100% of the CPU, without displaying any windows. I tried to remove the .kde/share/apps/konqueror, .kde/share/apps/rekonq, .kde/share/config/konquerorrc and .kde/share/config/rekonqrc files, but the problem still exists. I tried with another account on the same computer, and rekonq is able to start correctly. As you can see in the attached file, I tried "strace rekonq", and it seems that the binary stop during a poll: "poll([{fd=10, events=POLLIN}], 1, 25000" I don't know which configuration is different on the two accounts (my original one, and the other without bug). Reproducible: Didn't try