Bug 133313 - Browsing directories with large numbers of files in GtkFileChooser makes the UI unresponsive
Browsing directories with large numbers of files in GtkFileChooser makes the ...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gtk2 (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Matthias Clasen
:
Depends On:
Blocks: 131589
  Show dependency treegraph
 
Reported: 2004-09-22 22:33 EDT by Rodd Clarkson
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-01 01:26:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rodd Clarkson 2004-09-22 22:33:29 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Gecko/20040809

Description of problem:
With the current version of Evolution, each time I try to save an
attachment to disk, the CPU goes to 100% and evolution becomes
unresponsive.

Version-Release number of selected component (if applicable):
evolution-2.0.0-2

How reproducible:
Always

Steps to Reproduce:
Steps to reproduce:
1. Find an email with an attachment and view it.
2. Click the down arrow for the attachment and select "Save As"

Actual Results:  At this point my CPU goes wild and evolution stops
responding.

Expected Results:  I would expect evolution to save the file to disk

Additional info:

I noticed that evolution has be patched to use the new GTK File Picker
and I imagine this is related.

gtk2-2.4.9-9
glib2-2.4.6-1
Comment 1 Dave Malcolm 2004-09-23 10:55:50 EDT
Thanks for the bug report.  I sometimes get a slight pause when the
file chooser is used for the first time in evolution, but it always
comes back for me.

Please install the evolution-debuginfo package, and try to obtain a
backtrace of what evolution's doing, by running evolution inside gdb,
trying to reproduce the behaviour, pressing Ctrl-C in gdb (if it
hasn't stopped already), and typing "thread apply all backtrace". 
Then post the results here and hopefully that'll shed some light on
things...
Comment 2 Rodd Clarkson 2004-09-23 23:32:47 EDT
okay, here's the backtrace.  It's worth noting I never managed to see
the actual file save dialog, it crashes just clicking the down arrow
used to select "Save As".

[rodd@clownfish ~]$ gdb evolution-2.0
GNU gdb Red Hat Linux (6.1post-1.20040607.28rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host
libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) run
Starting program: /usr/bin/evolution-2.0
[Thread debugging using libthread_db enabled]
[New Thread -158005504 (LWP 5248)]
Detaching after fork from child process 5254.
asked to activate component_id
`OAFIID:GNOME_Evolution_Addressbook_Component:2.0'
[New Thread -166040656 (LWP 5255)]
[New Thread -176530512 (LWP 5256)]
[New Thread -187020368 (LWP 5257)]
[New Thread -197608528 (LWP 5258)]
[Thread -187020368 (LWP 5257) exited]
asked to activate component_id
`OAFIID:GNOME_Evolution_Addressbook_Component:2.0'
[New Thread -187020368 (LWP 5284)]
[New Thread -208241744 (LWP 5285)]
[New Thread -218731600 (LWP 5297)]
requesting object classid: attachment.0x8234438.43589.mixed.1
object_found: 1

Program received signal SIG33, Real-time event 33.
[Switching to Thread -218731600 (LWP 5297)]
0xf6fe9782 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) thread apply all backtrace

Thread 8 (Thread -218731600 (LWP 5297)):
#0  0xf6fe9782 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0xf6b7ca16 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/libpthread.so.0
#2  0x0333ac08 in e_msgport_wait (mp=0x81c03d8) at e-msgport.c:511
#3  0x0333b2c3 in thread_dispatch (din=0x81b9e80) at e-msgport.c:874
#4  0xf6b7a1dc in start_thread () from /lib/tls/libpthread.so.0
#5  0xf6a69dda in clone () from /lib/tls/libc.so.6

Thread 7 (Thread -208241744 (LWP 5285)):
#0  0xf6fe9782 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0xf6b7ca16 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/libpthread.so.0
#2  0x0333ac08 in e_msgport_wait (mp=0x81bec78) at e-msgport.c:511
#3  0x0333b2c3 in thread_dispatch (din=0x81bec20) at e-msgport.c:874
#4  0xf6b7a1dc in start_thread () from /lib/tls/libpthread.so.0
#5  0xf6a69dda in clone () from /lib/tls/libc.so.6

Thread 6 (Thread -187020368 (LWP 5284)):
#0  0xf6fe9782 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0xf6b7ca16 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/libpthread.so.0
---Type <return> to continue, or q <return> to quit---
#2  0x0333ac08 in e_msgport_wait (mp=0x81bec78) at e-msgport.c:511
#3  0x0333b2c3 in thread_dispatch (din=0x81bec20) at e-msgport.c:874
#4  0xf6b7a1dc in start_thread () from /lib/tls/libpthread.so.0
#5  0xf6a69dda in clone () from /lib/tls/libc.so.6

Thread 5 (Thread -197608528 (LWP 5258)):
#0  0xf6fe9782 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0xf6b7ca16 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/libpthread.so.0
#2  0x0333ac08 in e_msgport_wait (mp=0x81b9ef8) at e-msgport.c:511
#3  0x0333b2c3 in thread_dispatch (din=0x81beba8) at e-msgport.c:874
#4  0xf6b7a1dc in start_thread () from /lib/tls/libpthread.so.0
#5  0xf6a69dda in clone () from /lib/tls/libc.so.6

Thread 3 (Thread -176530512 (LWP 5256)):
#0  0xf6fe9782 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0xf6b7ca16 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/libpthread.so.0
#2  0x0333ac08 in e_msgport_wait (mp=0x81bec78) at e-msgport.c:511
#3  0x0333b2c3 in thread_dispatch (din=0x81bec20) at e-msgport.c:874
#4  0xf6b7a1dc in start_thread () from /lib/tls/libpthread.so.0
#5  0xf6a69dda in clone () from /lib/tls/libc.so.6

---Type <return> to continue, or q <return> to quit---
Thread 2 (Thread -166040656 (LWP 5255)):
#0  0xf6fe9782 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0xf6b7ca16 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/libpthread.so.0
#2  0x0333ac08 in e_msgport_wait (mp=0x81bec78) at e-msgport.c:511
#3  0x0333b2c3 in thread_dispatch (din=0x81bec20) at e-msgport.c:874
#4  0xf6b7a1dc in start_thread () from /lib/tls/libpthread.so.0
#5  0xf6a69dda in clone () from /lib/tls/libc.so.6

Thread 1 (Thread -158005504 (LWP 5248)):
#0  0xf6fe9782 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0xf6b79de0 in __nptl_setxid () from /lib/tls/libpthread.so.0
#2  0xf6a6253e in seteuid () from /lib/tls/libc.so.6
#3  0x035667c3 in gnome_vfs_method_init () from
/usr/lib/libgnomevfs-2.so.0
#4  0x035669b1 in gnome_vfs_transform_get () from
/usr/lib/libgnomevfs-2.so.0
#5  0x03576781 in gnome_vfs_uri_new_private () from
/usr/lib/libgnomevfs-2.so.0
#6  0x035768df in gnome_vfs_uri_new () from /usr/lib/libgnomevfs-2.so.0
#7  0x0357131d in gnome_vfs_monitor_add () from
/usr/lib/libgnomevfs-2.so.0
#8  0x0356a366 in gnome_vfs_mime_set_extensions_list ()
   from /usr/lib/libgnomevfs-2.so.0
#9  0x0356a7cb in gnome_vfs_mime_get_all_desktop_entries ()
   from /usr/lib/libgnomevfs-2.so.0
#10 0x03567cf1 in gnome_vfs_mime_get_all_applications ()
---Type <return> to continue, or q <return> to quit---
   from /usr/lib/libgnomevfs-2.so.0
#11 0x03567db3 in gnome_vfs_mime_get_short_list_applications ()
   from /usr/lib/libgnomevfs-2.so.0
#12 0xf64cb36d in emp_standard_menu_factory (emp=0x85633d8,
target=0x8597230,
    data=0x0) at em-popup.c:949
#13 0xf64c9f92 in em_popup_add_static_items (emp=0x85633d8,
target=0x8597230)
    at em-popup.c:210
#14 0xf64ca4b0 in em_popup_create_menu_once (emp=0x85633d8,
target=0x8597230,
    hide_mask=4294967292, disable_mask=4294967292) at em-popup.c:392
#15 0xf64bdedb in efhd_attachment_popup (w=0x8714f88, event=0x8183f18,
    info=0x8706348) at em-format-html-display.c:1102
#16 0xf6c93d77 in gtk_marshal_VOID__UINT_STRING ()
   from /usr/lib/libgtk-x11-2.0.so.0
#17 0x007c5347 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#18 0x007da94e in g_signal_has_handler_pending ()
   from /usr/lib/libgobject-2.0.so.0
#19 0x007dc613 in g_signal_emit_valist () from
/usr/lib/libgobject-2.0.so.0
#20 0x007dcc5a in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#21 0xf6d87845 in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0
#22 0xf6c9203b in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0
#23 0xf6c92340 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#24 0xf6b46092 in gdk_event_get_graphics_expose ()
   from /usr/lib/libgdk-x11-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#25 0x007624fb in g_main_context_dispatch () from
/usr/lib/libglib-2.0.so.0
#26 0x00763f82 in g_main_context_acquire () from /usr/lib/libglib-2.0.so.0
#27 0x0076422f in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#28 0xf6e9add5 in bonobo_main () from /usr/lib/libbonobo-2.so.0
#29 0x08063a69 in main (argc=6, argv=0xfef78244) at main.c:585
#0  0xf6fe9782 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) quit
The program is running.  Exit anyway? (y or n) y
[rodd@clownfish ~]$
Comment 3 Rodd Clarkson 2004-09-23 23:36:52 EDT
Interesting.  If I wait a while, the save as dialog does actually
work, but it takes for ever, and I'm now seeing 100% CPU (trying to
save the file?).

The later CPU issue lasted about 2 or 3 minutes.  The initial one was
a little longer (maybe 5 or 6).
Comment 4 Rodd Clarkson 2004-09-24 02:45:43 EDT
Okay, I've discovered something and this may shed some light on the
situation.  It may be that the GtkFileChoose is just struggling under
the weight of too many files.

If I do the Save As option, it's defaulting to /tmp.  This may be
because this is the default, or because it's the last place I saved
files, but it doesn't matter, other than it's using /tmp as the folder
of choice.

However, I tried to import a file into evolution I was hoping was
either a mbox or .mbx file (I'm still not sur, but again it doesn't
matter).  The file open dialog opened very quickly in ~, but when I
navigate to /tmp it bogs down and take about 1 minute to become
responsive.

This begs the question, what does /tmp have that ~ doesn't.  Let's see:

[rodd@clownfish tmp]$ ls ~ | wc && ls /tmp | wc
     28      32     361
   3368    3368   47406

It turns out that /tmp has about 100 times as many files as ~ and I
think might be causing the bog down.  The file/folder view seems to
spend a lot of time trying to 'index' all the files (along with their
mime-types?)

Comment 5 Rodd Clarkson 2004-09-24 02:47:07 EDT
Oh, and I should add, that the 5 or 6 minutes and 2 or 3 minutes are
actually only about 1 minute (on a P3-1GH) but of course when you're
weighting for your app to become responsive time seems relative.
Comment 6 Rodd Clarkson 2004-09-24 02:49:57 EDT
what the hell, while I'm babbling, it turns out that there are over
3279 tmp*.hdr files in my tmp directory.  I've been having huge
problems with getting up2date to work and maybe it's been adding them
willy-nilly, or maybe it was yum.  I'd be happy to delete these and
then try again if you think it might give some insight.
Comment 7 Dave Malcolm 2004-09-24 11:49:45 EDT
OK - thanks for all the info.   Looks like a generalised problem with
the GtkFileChooser's performance with directories containing large
numbers of files.  I'm going to rename and reclassify this bug
accordingly...
Comment 8 Matthias Clasen 2004-09-24 11:55:52 EDT
I'm looking into this now. It seems that the file chooser
synchronously determines the mime types of all files when changing to
a new folder.
That may involve reading the first few bytes of every file, and will
certainly take some time when there are thousands of files.
Comment 9 Matthias Clasen 2004-09-29 00:02:02 EDT
gtk2-2.4.10-5 has a fix for the completion popup freezing the ui.

Note You need to log in before you can comment on or make changes to this bug.