GNOME Bugzilla – Bug 523619
crash in Gnumeric Spreadsheet: I clicked 'save as', and...
Last modified: 2008-06-10 13:33:12 UTC
Version: 1.8.2 What were you doing when the application crashed? I clicked 'save as', and then in the dialog, 'cancel'. Distribution: Fedora Core release 3 (Heidelberg) Gnome Release: 2.22.0 2008-03-19 (GARNOME) BugBuddy Version: 2.22.0 System: Linux 2.6.20-1.2944_FC3asl.1smp #1 SMP Mon Apr 23 13:26:12 PDT 2007 x86_64 X Vendor: The X.Org Foundation X Vendor Release: 60801000 Selinux: No Accessibility: Disabled GTK+ Theme: Clearlooks Icon Theme: gnome Memory status: size: 159313920 vsize: 159313920 resident: 33452032 share: 16687104 rss: 33452032 rss_rlim: 18446744073709551615 CPU usage: start_time: 1206041516 rtime: 184 utime: 167 stime: 17 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/ita/gar64/bin/gnumeric' Using host libthread_db library "/lib64/tls/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 46912603248224 (LWP 28842)] [New Thread 1077934432 (LWP 29187)] [Thread debugging using libthread_db enabled] [New Thread 46912603248224 (LWP 28842)] [New Thread 1077934432 (LWP 29187)] [Thread debugging using libthread_db enabled] [New Thread 46912603248224 (LWP 28842)] [New Thread 1077934432 (LWP 29187)] 0x00002aaab04d2f7a in waitpid () from /lib64/tls/libpthread.so.0
+ Trace 192978
Thread 2 (Thread 1077934432 (LWP 29187)): #-1 0x00002aaab04cfacf in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 No symbol table info available.
Is this repeatable? If so, does it happen with the default theme?
(In reply to comment #1) > Is this repeatable? Yes. It happens every time I use the save-as dialog (which means I can no longer create new spreadsheets :) > If so, does it happen with the default theme? I believe I am using the default theme: System>Preferences>Appearance Theme tab : 'Clearlooks' selected
Repeatable is good, I guess. Could you try with some other theme, please? I was hoping for the gtk+ default theme, but I guess any other will do. Alternatively, does Fedora allow you to install debug information somehow? (For gtk+ -- the addresses suggest that the crash occurs inside gtk+.) Finally, does this happen if you run under valgrind? That might give us a bit more information.
I tried the 'darklooks' theme, and had the same results. I can happily install new themes via Systen>Appearance>Theme>Install so if you can point me to this default one, I'll happily install it and see what happens. Thanks.
*** Bug 524337 has been marked as a duplicate of this bug. ***
OK, I can reproduce this via the Save-As dialog in firefox. Should this bug be moved to gnome-themes ? Or gtk-engines ? Thanks.
> Should this bug be moved to gnome-themes ? Or gtk-engines ? That's a tough one. My out-of-the-hat guess is that there is memory corruption due to a theme problem. That would be a gtk-engines problem. However, there is no smoking gun so they might very well ask "why us?" if you reassign things there. But it's worth a try. gtk+ is another possible target as the crashes occur in gtk+ land. If you had access to a gtk+ build with debug information, things might be clearer.
I recompiled gtk+ with --enable-debug=yes. I get the following in STDOUT/STDERR: (gnumeric:6742): GLib-GObject-WARNING **: IA__g_object_new_valist: object class `GThemedIcon' has no property named `names' (gnumeric:6742): GLib-GIO-CRITICAL **: g_themed_icon_constructed: assertion `themed->names != NULL && themed->names[0] != NULL' failed (gnumeric:6742): GLib-CRITICAL **: g_strv_length: assertion `str_array != NULL' failed GLib-GObject-ERROR **: g_type_plugin_*() invalidly modified type `GLocalFileEnumerator' aborting... I also get a more detailed stacktrace (less inlining, I guess :) from bugbuddy: Using host libthread_db library "/lib64/tls/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 46912603584064 (LWP 6742)] [New Thread 1082128736 (LWP 6746)] [Thread debugging using libthread_db enabled] [New Thread 46912603584064 (LWP 6742)] [New Thread 1082128736 (LWP 6746)] [Thread debugging using libthread_db enabled] [New Thread 46912603584064 (LWP 6742)] [New Thread 1082128736 (LWP 6746)] [New Thread 1075837280 (LWP 6743)] 0x00002aaab05218da in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0
+ Trace 193382
Thread 3 (Thread 1075837280 (LWP 6743)): #-1 0x00002aaab0524f7a in waitpid () from /lib64/tls/libpthread.so.0 No symbol table info available.
Could you try running under gdb to get a stack trace of the first problem: gdb /path/to/gnumeric start b g_log c # Do the thing that causes trouble where The output from that is likely useful.
I did that, but it doesn't improve on what bugbuddy already caught at the top of this bug: $ gdb /ita/gar64/bin/gnumeric [...] (gdb) start Breakpoint 1 at 0x404b30: file main-application.c, line 325. Starting program: /ita/gar64/bin/gnumeric [Thread debugging using libthread_db enabled] [New Thread 46912603584064 (LWP 4620)] [Switching to Thread 46912603584064 (LWP 4620)] main (argc=0, argv=0x2aaaaabbfc40) at main-application.c:325 325 { (gdb) b g_log Breakpoint 2 at 0x2aaab09c9a00: file gmessages.c, line 513. (gdb) c Continuing. [New Thread 1075837280 (LWP 4695)] [New Thread 1077934432 (LWP 4696)] [New Thread 1080031584 (LWP 4698)] [New Thread 1082128736 (LWP 4699)] [Thread 1077934432 (LWP 4696) exited] [Thread 1075837280 (LWP 4695) exited] [Thread 1082128736 (LWP 4699) exited] Writing file:///ita/home/lpl/Book1.asdasdasd Program received signal SIGSEGV, Segmentation fault. 0x00002aaab26813d0 in ?? () (gdb) where #0 0x00002aaab26813d0 in ?? () #1 0x00002aaab09c1264 in IA__g_main_context_dispatch (context=0x5896d0) at gmain.c:2003 #2 0x00002aaab09c2d85 in g_main_context_iterate (context=0x5896d0, block=-1325744640, dispatch=1, self=0x0) at gmain.c:2636 #3 0x00002aaab09c310a in IA__g_main_loop_run (loop=0x6dfc80) at gmain.c:2844 #4 0x00002aaaae793e1b in bonobo_main () at bonobo-main.c:311 #5 0x0000000000404e49 in main (argc=5601280, argv=0x47ebb8b6) at main-application.c:473 (gdb)
The messages you are seeing appear to be coming from gio which was recently included in glib. What is the output of ldd -v /path/to/gnumeric ? I do note, however, that there was some very recent memory corruption fixed in gio: http://svn.gnome.org/viewvc/glib/trunk/gio/gthemedicon.c?r1=6655&r2=6666
The output from ldd is below. Grep shows no trace of 'gio'. I'll try that patch you pointed to, and see what happens. Thanks ! $ ldd /ita/gar64/bin/gnumeric libspreadsheet-1.8.2.so => /ita/gar64/lib/libspreadsheet-1.8.2.so (0x00002aaaaabc1000) libgoffice-0.6.so.6 => /ita/gar64/lib/libgoffice-0.6.so.6 (0x00002aaaaafaf000) libpcre.so.0 => /ita/gar64/lib/libpcre.so.0 (0x00002aaaab1c9000) libglade-2.0.so.0 => /ita/gar64/lib/libglade-2.0.so.0 (0x00002aaaab2e8000) libgnomeui-2.so.0 => /ita/gar64/lib/libgnomeui-2.so.0 (0x00002aaaab402000) libgnome-keyring.so.0 => /ita/gar64/lib/libgnome-keyring.so.0 (0x00002aaaab59e000) libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00002aaaab6b0000) libbonoboui-2.so.0 => /ita/gar64/lib/libbonoboui-2.so.0 (0x00002aaaab7d2000) libgnomecanvas-2.so.0 => /ita/gar64/lib/libgnomecanvas-2.so.0 (0x00002aaaab941000) libgailutil.so.18 => /ita/gar64/lib/libgailutil.so.18 (0x00002aaaaba76000) libart_lgpl_2.so.2 => /ita/gar64/lib/libart_lgpl_2.so.2 (0x00002aaaabb7f000) libgtk-x11-2.0.so.0 => /ita/gar64/lib/libgtk-x11-2.0.so.0 (0x00002aaaabc96000) libgdk-x11-2.0.so.0 => /ita/gar64/lib/libgdk-x11-2.0.so.0 (0x00002aaaac195000) libXrandr.so.2 => /usr/X11R6/lib64/libXrandr.so.2 (0x00002aaaac362000) libXi.so.6 => /usr/X11R6/lib64/libXi.so.6 (0x00002aaaac465000) libXinerama.so.1 => /usr/X11R6/lib64/libXinerama.so.1 (0x00002aaaac56d000) libXext.so.6 => /usr/X11R6/lib64/libXext.so.6 (0x00002aaaac670000) libatk-1.0.so.0 => /ita/gar64/lib/libatk-1.0.so.0 (0x00002aaaac781000) libgdk_pixbuf-2.0.so.0 => /ita/gar64/lib/libgdk_pixbuf-2.0.so.0 (0x00002aaaac8a2000) libpangocairo-1.0.so.0 => /ita/gar64/lib/libpangocairo-1.0.so.0 (0x00002aaaac9bb000) libpangoft2-1.0.so.0 => /ita/gar64/lib/libpangoft2-1.0.so.0 (0x00002aaaacac6000) libXcursor.so.1 => /ita/gar64/lib/libXcursor.so.1 (0x00002aaaacbf1000) libXcomposite.so.1 => /usr/X11R6/lib64/libXcomposite.so.1 (0x00002aaaaccfb000) libXdamage.so.1 => /usr/X11R6/lib64/libXdamage.so.1 (0x00002aaaacdfd000) libXfixes.so.3 => /usr/X11R6/lib64/libXfixes.so.3 (0x00002aaaaceff000) libpango-1.0.so.0 => /ita/gar64/lib/libpango-1.0.so.0 (0x00002aaaad005000) libcairo.so.2 => /ita/gar64/lib/libcairo.so.2 (0x00002aaaad148000) libfontconfig.so.1 => /ita/gar64/lib/libfontconfig.so.1 (0x00002aaaad2ca000) libfreetype.so.6 => /ita/gar64/lib/libfreetype.so.6 (0x00002aaaad3ff000) libexpat.so.0 => /usr/lib64/libexpat.so.0 (0x00002aaaad57c000) libglitz.so.1 => /ita/gar64/lib/libglitz.so.1 (0x00002aaaad69e000) libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00002aaaad7c9000) libSM.so.6 => /usr/X11R6/lib64/libSM.so.6 (0x00002aaaad8f0000) libICE.so.6 => /usr/X11R6/lib64/libICE.so.6 (0x00002aaaad9fa000) libXrender.so.1 => /ita/gar64/lib/libXrender.so.1 (0x00002aaaadb16000) libX11.so.6 => /usr/X11R6/lib64/libX11.so.6 (0x00002aaaadc1e000) libgnome-2.so.0 => /ita/gar64/lib/libgnome-2.so.0 (0x00002aaaaddff000) libesd.so.0 => /ita/gar64/lib/libesd.so.0 (0x00002aaaadf17000) libasound.so.2 => /lib64/libasound.so.2 (0x00002aaaae021000) libaudiofile.so.0 => /ita/gar64/lib/libaudiofile.so.0 (0x00002aaaae1e6000) libpopt.so.0 => /ita/gar64/lib/libpopt.so.0 (0x00002aaaae311000) libgsf-gnome-1.so.114 => /ita/gar64/lib/libgsf-gnome-1.so.114 (0x00002aaaae419000) libgsf-1.so.114 => /ita/gar64/lib/libgsf-1.so.114 (0x00002aaaae51e000) libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x00002aaaae658000) libbonobo-2.so.0 => /ita/gar64/lib/libbonobo-2.so.0 (0x00002aaaae767000) libgnomevfs-2.so.0 => /ita/gar64/lib/libgnomevfs-2.so.0 (0x00002aaaae8da000) libdbus-glib-1.so.2 => /ita/gar64/lib/libdbus-glib-1.so.2 (0x00002aaaaea40000) libnsl.so.1 => /lib64/libnsl.so.1 (0x00002aaaaeb60000) libssl.so.4 => /lib64/libssl.so.4 (0x00002aaaaec77000) libcrypto.so.4 => /lib64/libcrypto.so.4 (0x00002aaaaedb4000) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00002aaaaefe2000) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002aaaaf0f8000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002aaaaf26a000) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002aaaaf36c000) libavahi-glib.so.1 => /ita/gar64/lib/libavahi-glib.so.1 (0x00002aaaaf48f000) libavahi-client.so.3 => /ita/gar64/lib/libavahi-client.so.3 (0x00002aaaaf593000) libdbus-1.so.3 => /ita/gar64/lib/libdbus-1.so.3 (0x00002aaaaf6a3000) libavahi-common.so.3 => /ita/gar64/lib/libavahi-common.so.3 (0x00002aaaaf7dd000) libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaaf8ea000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00002aaaaf9ed000) libutil.so.1 => /lib64/libutil.so.1 (0x00002aaaafb02000) libxml2.so.2 => /ita/gar64/lib/libxml2.so.2 (0x00002aaaafc06000) libz.so.1 => /usr/lib64/libz.so.1 (0x00002aaaafe44000) libbonobo-activation.so.4 => /ita/gar64/lib/libbonobo-activation.so.4 (0x00002aaaaff57000) libORBitCosNaming-2.so.0 => /ita/gar64/lib/libORBitCosNaming-2.so.0 (0x00002aaab0072000) libgconf-2.so.4 => /ita/gar64/lib/libgconf-2.so.4 (0x00002aaab0179000) libORBit-2.so.0 => /ita/gar64/lib/libORBit-2.so.0 (0x00002aaab02ac000) libgthread-2.0.so.0 => /ita/gar64/lib/libgthread-2.0.so.0 (0x00002aaab0415000) libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x00002aaab0519000) librt.so.1 => /lib64/tls/librt.so.1 (0x00002aaab062e000) libgmodule-2.0.so.0 => /ita/gar64/lib/libgmodule-2.0.so.0 (0x00002aaab0749000) libgobject-2.0.so.0 => /ita/gar64/lib/libgobject-2.0.so.0 (0x00002aaab084c000) libglib-2.0.so.0 => /ita/gar64/lib/libglib-2.0.so.0 (0x00002aaab098d000) libXxf86vm.so.1 => /usr/X11R6/lib64/libXxf86vm.so.1 (0x00002aaab0b5f000) libXtst.so.6 => /usr/X11R6/lib64/libXtst.so.6 (0x00002aaab0c64000) libm.so.6 => /lib64/tls/libm.so.6 (0x00002aaab0d6a000) libc.so.6 => /lib64/tls/libc.so.6 (0x00002aaab0ef1000) /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000)
That patch is already present in glib-2.16.1, which is what I'm running :/
Good news - this bug has been fixed, somewhere, as part of Gnome 2.22.1. Hoorah ! I'll close this now, to reduce your open big count :)
This is likely a dupe of bug 537555.