Note how the "at-spi-registryd" process appears next to nautilus.
I'm attaching 3 gdb backtraces.
To obtain these:
1. Install debug packages "nautilus-dbg", "libgtk2.0-0-dbg", "libglib2.0-0-dbg", "libatk1.0-dbg".
2. Completely close nautilus with "nautilus --quit"
3. Run the debugger "gdb nautilus" as described here https://wiki.ubuntu.com/Backtrace
4. I try to open /usr/bin which is guaranteed to have at least 1500 files.
5. Nautilus will eventually load the directory, but you need to wait at least 2.5 minutes on a slow computer. The time increases with the number of files.
6. Interrupt the process in the terminal with Ctrl+C. You may do this while nautilus is still unresponsive; if you wait for it to finish loading the directory you won't have anything interesting in the backtrace.
In the first backtrace the only library without symbols is "/usr/lib/gtk-2.0/modules/libatk-bridge.so", which is included in the "at-spi" package, which also provides "/usr/lib/at-spi/at-spi-registryd"
7. To obtain the other two backtraces install the debug symbols for this library, which are found in "libatspi-dbg"
8. Briefly looking at the source code in gail/gailtreeview.c, iterate_thru_children() is a recursive function, and according to one backtrace it is called a gazillion times.
9. The other backtrace shows a different output. You can run gdb several times to get different outputs each time, depending on the moment you hit Ctrl+C. I tested this on a single core, AMD64 processor, running 32-bit Ubuntu 8.10. If you have a multicore machine, you'll see threads everywhere in the backtraces.
10. Running "valgrind" with nautilus takes a LOT of time to even start. It outputs several lines concerning python2.5 and python libraries, which I believe is totally unrelated to this bug.
This is related to bug #267051. You can tell by the upstream bug report.
A similar Debian bug report is here bugs.debian. org/cgi- bin/bugreport. cgi?bug= 506715
http://
Note how the "at-spi-registryd" process appears next to nautilus.
I'm attaching 3 gdb backtraces.
To obtain these: /wiki.ubuntu. com/Backtrace
1. Install debug packages "nautilus-dbg", "libgtk2.0-0-dbg", "libglib2.0-0-dbg", "libatk1.0-dbg".
2. Completely close nautilus with "nautilus --quit"
3. Run the debugger "gdb nautilus" as described here https:/
4. I try to open /usr/bin which is guaranteed to have at least 1500 files.
5. Nautilus will eventually load the directory, but you need to wait at least 2.5 minutes on a slow computer. The time increases with the number of files.
6. Interrupt the process in the terminal with Ctrl+C. You may do this while nautilus is still unresponsive; if you wait for it to finish loading the directory you won't have anything interesting in the backtrace.
In the first backtrace the only library without symbols is "/usr/lib/ gtk-2.0/ modules/ libatk- bridge. so", which is included in the "at-spi" package, which also provides "/usr/lib/ at-spi/ at-spi- registryd"
7. To obtain the other two backtraces install the debug symbols for this library, which are found in "libatspi-dbg" ew.c, iterate_ thru_children( ) is a recursive function, and according to one backtrace it is called a gazillion times.
8. Briefly looking at the source code in gail/gailtreevi
9. The other backtrace shows a different output. You can run gdb several times to get different outputs each time, depending on the moment you hit Ctrl+C. I tested this on a single core, AMD64 processor, running 32-bit Ubuntu 8.10. If you have a multicore machine, you'll see threads everywhere in the backtraces.
10. Running "valgrind" with nautilus takes a LOT of time to even start. It outputs several lines concerning python2.5 and python libraries, which I believe is totally unrelated to this bug.
ECC