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
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 :-)