GNOME Bugzilla – Bug 129963
nautilus locks up during window resize (compact mode)
Last modified: 2009-03-23 18:16:52 UTC
In icon view mode, and in the home directory, nautilus locks up if I try to create a new directory. I have to kill the window to close it, then if I open a new one, that locks up immediately. Same effect if I move one (home) directory into another (home) directory.
After more experimentation, I think this is to do with the size of the directory window relative to what is in it. I can get nautilus to lock just be resizing the window to the 'correct' size. If the window size is sufficiently far from this correct value, I have no problem creating or moving directories.
Recipe for creating bug (sufficient): Create a directory, put 31 subdirectories in it, and 4 files. Select icon view, compact layout. Have different directory name lengths. Re-size the window so that there are 5 rows (and no more). Some rows should have 8 directories, other rows 7 (because of different name lengths). Re-size the window height (in small steps) until the vertical scroll bar disappears. Nautilus will probably lock now, if not try re-sizing wider.
I see this bug quite often too. Here is a backtrace of a locked up Nautilus obtained with SIGABRT:
+ Trace 50791
Thread 1 (Thread -150960992 (LWP 11200))
Ricardo: you get that when resizing a nautilus window? Maybe this is a duplicate of bug 122141.
Yes, I get this when resizing some windows. But also when opening certain folders (not 100% reproducible, but some folders trigger this bug most times). This happens only with the "compact layout" (or at least I haven't been able to reproduce the bug without it). I don't think this is a duplicate of 122141, here nautilus doesn't crash, it just locks up.
In Fedora Core 3, Nautilus still locks up (uses 100% cpu) when folder windows are resized (sometimes). Is there anything I can do to help getting this fixed?
I have this as well, with GNOME 2.8.1 (Gentoo). I think it has been there since GNOME 2.6, having this bug since quite a long time. The bug is definitely related to Compact mode, and occurs when resizing certain windows. In some cases, after the 100% cpu hang and killing nautilus, the same directory window can be opened without problems (although the resize is rolled back). In other cases, opening the same directory results in 100% cpu hang immediately, and the size of the directory is as intended (resize worked).
2.10 does include this bug also. And it's a very, very annoying one. I'd love to use compact layout, but this bug prevents using compact layout.
*** Bug 312998 has been marked as a duplicate of this bug. ***
Getting a 100% CPU freeze resizing a window which is NOT in compact mode here. Attached gdb, got a backtrace. It seemed to me that it froze when the window became wide enough to fit one extra column of icons at the right. Perhaps this is the same, perhaps it is different. But it seems pretty similar. (gdb) bt
+ Trace 62444
I can confirm the lock up, when randomnly resizing a window excessively.
While I could this still verify this for Nautilus 2.12.0, I was unable to reproduce it with Nautilus 2.12.1, probably due to the icon container layout fixes we committed that also prevent Nautilus from displaying a horizontal scrollbar that possbily triggered an endless size change recursion for the container.
*** Bug 160128 has been marked as a duplicate of this bug. ***
I have reproduced this bug with nautilus 2.12.1. In fact I have found a way to consistently reproduce it: Nautilus 2.12.1, default settings, enable "compact mode". - Create a new folder. - Open the folder - Create 5 new folders in it, folder1 through folder5 - Copy 4 PNG files in (previewed, larger than folder icon) - Copy a PDF file in (with dimensions like an A4 paper, previewed) - Resize the folder for a while (fullscreen, very small etc.) - Eventually I get 100% cpu by nautilus. I believe this bug is still there, think the bug should be reopened. Can anyone confirm?
Thanks for your info Mark, I can still reproduce it. Reopening.
Time to take another look at this. I am seeing the 100% CPU usage and unresponsive Nautilus here with 2.16.3. This happens frequently when using Compact layout, and less frequently with normal layout. I suspect that the program is going into an infinite loop trying to find an optimal layout for the icons in the folder. If so, then one simple workaround may be to put an upper limit on the number of loop iterations allowed for computing the layout. This bug can be fairly easily reproduced for a given folder which contains many icons. Just grab one corner of the Nautilus window and slowly move the mouse around in a roughly circular pattern, so that Nautilus reflows the icons frequently. This procedure is not guaranteed to work, however, since triggering the bug seems to involve hitting a particular combination of icons and window size. Sometimes one finds that Nautilus will hang this way consistently when one attempts to display a folder. I believe you can work around this by displaying a different folder, resizing Nautilus, closing Nautilus, and then viewing the problematic folder. Alternatively, one can create a file that's displayed early (e.g., by doing 'touch 00' in the problematic folder) to change the layout enough to avoid the hang. This bug has been around since version 2.0. It's a pretty long-lived one for being so nasty and so well reported!
Created attachment 131068 [details] Lock-up in icon layout code; astable state 1. This is how the icons are originally laid out: notice the tall thumbnail in the second row. It is tall enough to push the third line below the bottom of the allocation size.
Created attachment 131069 [details] Lock-up in icon layout code; astable state 2. This is what the layout code comes up with when it notices that there isn't enough room for the canvas in the current allocation. A taller but narrower area is allocated, which surprisingly manages to fit all the icons and remain with some room extra. So the scrollbar isn't needed anymore, it goes away, and we go back to state 1.
I have also been a long-suffering subject of this one particular bug, so I whipped out gdb and went into a bug hunt. I did find what was causing it, but how to fix it, now that's a different matter altogether. The problem lies in icon view's layout mechanism. It can be reproduced fairly easily by following these steps: - Open a Nautilus window showing compact icon view of an empty directory. - Create a handful of directories in it. (It is not necessary that these be directories, but their icons are small and suitable for the purpose here) - Toss in one file with a tall thumbnail (portrait images and PDFs work well for this purpose). - Add another file to the directory that is *taller* than a directory thumbnail, but *shorter* than the tall thumbnail we just put in. (This is important.) Rename it so that alphabetically it comes after the tall thumbnail file. - You should now have a bunch of directories, one tall thumbnail, and one not so tall thumbnail in your window. Enlarge the window vertically so there's ample space below the contents, but fit the width in such a manner that the tall thumbnail is the only icon "sticking out" on the right side. It has to be the last icon in a row, and it has to be as close to the edge as possible. (You can rename some directories -- which changes the icon's size -- to make it happen.) The tall icon needs, in effect, to sit on the area where the scrollbar appears. - Make sure that the mid-sized file is sitting alone on the last line. Decrease the window height until you begin to cover that last file. Nautilus hangs. The explanation is rather simple: layout code notices when the allocation size becomes larger than the canvas, so it allocates a new region, longer but narrower by the scrollbar's width. However, by doing that, the tall icon from the next-to-last row can't fit in that row anymore; it flows onto the last row, which becomes only a little taller (thanks to the small difference in height between the two files), but the next-to-last row, having lost the tall icon, becomes significantly shorter (owing to the big difference in height between the tall icon and the directory icons). This causes the canvas to draw itself on an area that is shorter than the allocation, rendering the scrollbar unnecessary. Thus a new layout is fired, with the original allocation; the tall icon again pushes the last line just out of the allocation border, and the sequence repeats (ad nauseam). I took two screenshots illustrating the principle; they are in the attachments. Note that these are actual screenshots of the issue, only some critical blocks of code have been commented out, so I can photograph the two fighting layouts in slo-mo. I looked a bit into the code and it seems that it doesn't do any good to add a fixed margin to any of the layout components -- EelCanvas, NautilusIconContainer -- because that would just relocate the "magic" width at which directories like the one I described throw the layout code into a fit. The only thing I could come up with, after having spent two frustrating days with the old (and unmaintained?) Eazel code, was to change the vertical scrollbar policy in fm_directory_view_init to ALWAYS. This does solve the issue -- there can be no more trespassing on the scrollbar zone -- but can't possibly be called a solution. I leave this matter in more capable hands now. :)
The explanation is rather simple: layout code notices when the allocation size becomes larger than the canvas Diff: should be "becomes *smaller* than the canvas".
Created attachment 131134 [details] [review] Makes the rows in tighter layout (Compact layout in GUI) padded so they fill the icon canvas. As a side effect, it fixes bug 129963. This patch will make Compact layout views to flow the icons border-to-border, leaving no gap between the last icon in a row and the right edge of the canvas. This behavior might be undesired -- please test and let me know if I should pursue this line any further (it may still cause the bug 129963 to appear if a row is 1 pixel wider than other rows due to rounding, that needs to be investigated).
Created attachment 131146 [details] [review] Flowing compact layout; solves 129963. I speak of rounding errors, and use int to declare a padding constant. :)
Created attachment 131168 [details] [review] Fix for 129963 Well, my previous "fix" wasn't a fix at all; it just made the issue harder to spot. Here is a true solution, an ugly one to be sure, but it does avoid the endless re-laying out of the NautilusIconContainer. Side effects may include extraneous scrollbars in those situations which would otherwise cause the container to oscillate between the two geometries. I am still pretty sure that there is a better way to do this. Can I haz feedback? P.S. I still like the "flowing" layout from the previous attachment. If you have a chance, please do test it and consider it as a modification to the Compact view.
Thanks for tracking this down, especially with the testcase. Fixed in trunk: 2009-03-23 Alexander Larsson <alexl@redhat.com> Bug 129963 – nautilus locks up during window resize (compact mode) * libnautilus-private/nautilus-icon-container.c: * libnautilus-private/nautilus-icon-private.h: Work around possible infinite loop when relayouting by counting the number of iterations. This could happen in certain cases in with the compat mode. We use a clear-counter-at-idle-hack to detect the end of the loop.
An excellent fix, Alex; I was finally on the right track, but you killed it with the grace of an experienced dev. :)