After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 552880 - Nautilus freezes when entering directory
Nautilus freezes when entering directory
Status: RESOLVED OBSOLETE
Product: nautilus
Classification: Core
Component: general
2.22.x
Other All
: High critical
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-09-19 11:30 UTC by Conrad Bebbington
Modified: 2014-01-13 19:48 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22


Attachments
Stack trace (16.61 KB, text/plain)
2008-09-19 18:52 UTC, Conrad Bebbington
Details

Description Conrad Bebbington 2008-09-19 11:30:35 UTC
Steps to reproduce:
I first noticed this when navigating through my music collection but the filenames alone seem to crash it.

1. Create a directory.

2. In a terminal enter the directory and touch the following files:
01. Rex The Dog - Intro.mp3
02. Rex The Dog - Maximize 2008.mp3
03. Rex The Dog - Gecko.mp3
04. Rex The Dog - Bubblicious.mp3
05. Rex The Dog - Prototype.mp3
06. Rex The Dog - Heartsong.mp3
07. The Knife - Heartbeats (Rex The Dog Remix).mp3
08. Rex The Dog - Circulate.mp3
09. The Sounds - Tony The Beat (Rex The Dog Remix).mp3
10. Rex The Dog - I Can See You, Can You See Me?.mp3
11. Rex The Dog - Itchy Scratchy.mp3
12. Rex The Dog - Italian Skyline.mp3
13. Rex The Dog - Frequency.mp3
14. Rex The Dog - I Look Into Mid Air.mp3

3. Navigate to the directory in nautilus.


Stack trace:


Other information:
Running Gentoo on amd64.
Comment 1 palfrey 2008-09-19 17:10:23 UTC
Thanks for taking the time to report this bug.
Without a stack trace from the crash it's very hard to determine what caused it.
Can you get us a stack trace? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance!
Comment 2 Conrad Bebbington 2008-09-19 18:52:26 UTC
Created attachment 119010 [details]
Stack trace

Hope this is ok. Had to launch bug buddy manually.
Comment 3 palfrey 2008-10-28 17:22:11 UTC
Thanks, that's very helpful. Copying here for ease of searching:

  • #1 nautilus_icon_canvas_item_get_text_rectangle
    at nautilus-icon-canvas-item.c line 2272
  • #2 lay_down_icons
    at nautilus-icon-container.c line 1093
  • #3 redo_layout_internal
    at nautilus-icon-container.c line 1708

(Bug 517315 may also be a duplicate, but stacktrace there is awful)

There's been quite a lot of work since 2.22.3 in that file (Details for other developers: http://svn.gnome.org/viewvc/nautilus/trunk/libnautilus-private/nautilus-icon-canvas-item.c?r1=14182&r2=14704). Is there any way you can try this out with a 2.24 release of Nautilus instead? Thanks for all your help in this!
Comment 4 Christian Neumair 2008-10-28 17:51:17 UTC
It is probably the endless reallocation icon view bug that has been an issue for many years. A scrollbar is added and removed all the time, causing an oscillating endless recursion behavior.

It happened rarely with previous (<2.24) versions because if you have a large border around the canvas items, but happens more often with the new compact icon view. It also happened with the manual icon view layout, but wasn't noticed because virtually nobody used that mode.

If you remove all the right and bottom canvas borders, it can be easily triggered by resizing the window in diagonal direction on the handle back and forth.

I tried to trace the root of the issue, and it turned out that as the widget size is allocated, and we decide to add or remove the scroll bar, a relayout is requested. This is partly due to GTK+'s scrolled window, i.e. gtk_scrolled_window_size_allocate().

IIRC, the loop was like:

0 size_allocate() of the outer scrolled window is called

1 our size_allocate() is called by the window, we request size A requiring a scroll bar in do_relayout()
2 scrolled window's size_allocate() wants to add the scroll bar, re-runs size_allocate()
3 our size_allocate() is called by the window, we request size A requiring a scroll bar in do_relayout()
2 scrolled window's size_allocate() wants to remove the scroll bar, re-runs size_allocate()
5 goto 1

I never had any deep understanding of the GTK+ widget allocation concept and how exactly the size allocation of the eel canvas works, and why the issue doesn't affect other widgets. I couldn't find any documentation either. It would probably be appropriate to toggle the visibility only once in gtk_scrolled_window_size_allocate().
Comment 5 Christian Neumair 2008-10-28 17:54:16 UTC
yeah that's it with c'n'p when you are overslept. The correct reallocation sequence:

1 our size_allocate() is called by the window, we request size A requiring a
scroll bar in do_relayout()
2 scrolled window's size_allocate() wants to add the scroll bar, re-runs
size_allocate()
3 our size_allocate() is called by the window, we request size B not requiring a
scroll bar in do_relayout()
2 scrolled window's size_allocate() wants to remove the scroll bar, re-runs
size_allocate()
5 goto 1
Comment 6 Jean-François Fortin Tam 2014-01-12 16:14:41 UTC
Hi there, is this still a problem with the latest version?
Comment 7 Conrad Bebbington 2014-01-13 19:46:44 UTC
Not seen recently. Think you can close the bug. (would do it myself but not sure which resolution to pick)