GNOME Bugzilla – Bug 88931
nautilus hangs with 100% CPU when switching to list view
Last modified: 2004-12-22 21:47:04 UTC
Description of Problem: With a CVS checkout from today, switching to list view causes nautilus to hang, eating up 100% of the CPU. Steps to reproduce the problem: 1. choose "view as list" Actual Results: List headers are displayed, then nautilus hangs (no window redraws). Expected Results: Display list view. How often does this happen? Every time.
Attaching GDB to the nautilus process, I get the following repeat in the stack trace:
+ Trace 25396
It is caught in a loop trying to compute the size of the tree.
Gar. James, could you post the entire stack trace into the bug please (not as an attachment, but into the body)? It helps with debugging, and also some automatic bug duplication tools need the entire stack trace to work :-). Thanks a lot.
Urm... sorry, didn't realise you were a gnome hacker. Nevertheless, the whole stack trace would help when (and if) duplicates flood in.
The problem was originally pointed out by a user of #gnome. I was able to reproduce the problem, and posted the results above. This is not a crash, but rather a hang. It is also a tight recursive loop, so the stack trace is huge. Here is the beginning of the stack trace, omitting the repeating section of the stack. It is not identical to the previous trace, as I am breaking into running code, rather than tracing a segfault. I went through past the repeating section, and included the stack trace up to the control boundary (I assume this is the view object). I noticed that there is some GtkSizeGroup related frames. Could this be a bad interaction between size groups and tree views? What do you think, jrb?
+ Trace 25403
Same thing for me except mine crashes.
are you seeing an immediate crash (which might be a different bug), or a period of high CPU activity with the symptoms I described then a crash (which might indicate that the stack was exhausted)? If it is a crash with different symptoms, you might be seeing a different bug.
Hrm. Somehow Jonathan Taylor's email got removed from CC when I submitted then :(
For me it will use 100% CPU for a 10 secs or so and then crash.
That crash is prolly due to a stack overflow. I'm not sure what's going on here -- even if something catastrophic happens, that loop there should exit. I'll try to look into it.
It looks like this was broken by federico's recent EelBackground changes, particularly the stuff dealing with the style. I'm about to replace all of the EelBackgroundStyle anyway, so this issue will go away. jrb, if you want to be able to reproduce this you'll want to use eel and nautilus from 7-23.
Critical, high, bad, etc., etc. Sorry I'm so slow this week :/
Just updated eel and nautilus on my machine and performed the same test. The list view came up without a problem. This gets rid of the problem in nautilus, but the bad GtkTreeView/GtkSizeGroup interaction that jrb may want to trace.
Reassigning to gtk-tree-view since there is fixage in nautilus. jrb/kris/etc, do with as you please.
No clue what to do with this bug. Jonathan? You got anything to add?
Please REOPEN if needed.