GNOME Bugzilla – Bug 338847
Crash after Save+Quit
Last modified: 2006-04-18 21:26:03 UTC
Distribution: Slackware Slackware 10.2.0 Package: Gnumeric Severity: critical Version: GNOME2.12.1 unspecified Gnome-Distributor: FRG gsb.sourceforge.net build for slackware Synopsis: Typing ^S ^Q too quickly crashes gnumeric Bugzilla-Product: Gnumeric Bugzilla-Component: General Bugzilla-Version: unspecified BugBuddy-GnomeVersion: 2.0 (2.12.0) Description: Description of the crash: When I type ^Q while it is still processing ^S, rather than queueing the ^Q or ignoring it, gnumeric crashes Steps to reproduce the crash: 1. open a spreadsheet 2. make a change 3. type ^S^Q Expected Results: save and then cleanly quit How often does this happen? Every time Additional Information: This has been around for a while IIRC. This is with freerick gnome installed on top of Slackware 10.2 Debugging Information: Backtrace was generated from '/usr/bin/gnumeric' (no debugging symbols found) Using host libthread_db library "/lib/tls/libthread_db.so.1". (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1230920000 (LWP 12807)] 0xb7b1087e in __waitpid_nocancel () from /lib/tls/libc.so.6
+ Trace 67677
Thread 1 (Thread -1230920000 (LWP 12807))
------- Bug created by bug-buddy at 2006-04-18 02:16 -------
There is no reason ^Q should be doing anything at this point, unless you are setup to make ^Q send gnumeric a signal. Could you try running under gdb from the beginning in order to see what signal it is getting? Also, what gnumeric version are we talking about?
(In reply to comment #1) > There is no reason ^Q should be doing anything at this point, unless > you are setup to make ^Q send gnumeric a signal. I'm not sure why you say that. ^Q is a "keyboard accelerator" for File/Quit, so it seems to me that it should make gnumeric quit. Can you clarify to me why you don't think it should be doing anything at that point? > Could you try running under gdb from the beginning in order to see what > signal it is getting? Today it was feeling better, and it took me a couple of tries before it crashed and burned. Here is what I did gdb /usr/bin/gnumeric (gdb) run <open a spreadsheet, change a field> ^S^Q Starting program: /usr/bin/gnumeric (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1230956864 (LWP 13843)] Reading file:///home/zsd/courses/data-compression-winter-2006/aaa.xls Excel 97 + Writing file:///home/zsd/courses/data-compression-winter-2006/aaa.xls Writing file:///home/zsd/courses/data-compression-winter-2006/aaa.xls Writing file:///home/zsd/courses/data-compression-winter-2006/aaa.xls ** (gnumeric:13843): CRITICAL **: sheet_cell_get: assertion `IS_SHEET (sheet)' failed Program received signal SIGSEGV, Segmentation fault.
+ Trace 67687
Thread NaN (LWP 13843)
Was there any other info you would find useful? Just let me know. > Also, what gnumeric version are we talking about? Freerock gnome for Slackware 10.2 comes with 1.5.90, as you can see from the back trace above. Hmmm... "excel.so"... a crash with some M$ stuff... that makes more sense now :-)
> Can you clarify to me > why you don't think it should be doing anything at that point? The code at the crash point is not looking at mouse/keyboard/etc input. You are getting the crash in the exact same location, I notice. This is probably not related to ^Q at all, but is more likely a memory corruption during the write process. Can you share a copy of that sheet? (Attach here if you don't mind the world to see it; email if you want to keep it confidential.)
(In reply to comment #3) > > Can you clarify to me > > why you don't think it should be doing anything at that point? > > The code at the crash point is not looking at mouse/keyboard/etc input. OK, I see what you meant now. > You are getting the crash in the exact same location, I notice. This is > probably not related to ^Q at all, but is more likely a memory corruption > during the write process. And yet I never see this unless I type ^S^Q in very quick sequence. So I have mostly learned not to do that. Marx Brothers fans will appreciate the humour. > Can you share a copy of that sheet? (Attach here if you don't mind the > world to see it; email if you want to keep it confidential.) Note to other people... the sheet contains somewhat confidential info, so I emailed it to Morten directly.
I cannot replicate this with current cvs HEAD under purify, so chances are that there no longer is a problem. There are ~250 news items logged since 1.5.90 was released, so you are missing out on a lot of fixes. I'll leave this open so we can get an update when and if it becomes convenient for you to update. The current stable version is 1.6.3.
(In reply to comment #5) > I cannot replicate this with current cvs HEAD under purify, so chances > are that there no longer is a problem. There are ~250 news items logged > since 1.5.90 was released, so you are missing out on a lot of fixes. > I'll leave this open so we can get an update when and if it becomes > convenient for you to update. The current stable version is 1.6.3. I just took a look, and I see that Requested 'libgsf-1 >= 1.13.2' but version of libgsf-1 is 1.12.3 Requested 'libgoffice-1 >= 0.2.1' but version of libGOffice is 0.0.4 so I have to update a number of things (**sigh**). I'm afraid this has to go on the back burner for the rest of the week (I will have to compile all dependencies from source, and I am worried about the dependency tree going wild on me), but I will update when I am able to get at it. Thanks.
(In reply to comment #5) > I cannot replicate this with current cvs HEAD under purify, so chances > are that there no longer is a problem. There are ~250 news items logged > since 1.5.90 was released, so you are missing out on a lot of fixes. > > I'll leave this open so we can get an update when and if it becomes > convenient for you to update. The current stable version is 1.6.3. I just compiled and installed libgsf-1.14.0 goffice-0.2.1 and gnumeric-1.6.3-i386-1 This new version crashes when I try to open even very innocuous spreadsheets. I could open a new bug report for that as well, but I don't think it helps the current issue be resolved. Incidentally, did you try the ^S^Q a number of times while exporting in excel format? And maybe with a complex spreadsheet? In today's testing a couple of times it took me 4 or 5 tries to crash it. If, in fact, it is OK in your version, that's great, maybe some time in the future I'll be able to get all the gnomish parts of my system to play nicely together. Cheers.
You might need to run "ldconfig". Try also ldd `which gnumeric` to see what you are actually linked against. You could very well have two versions installed.
(In reply to comment #8) > You might need to run "ldconfig". Try also > > ldd `which gnumeric` > > to see what you are actually linked against. You could very well have two > versions installed. I do have two versions installed. One is in /usr/bin, the one I compiled (and the libraries I compiled) are in /usr/local/... Ran ldconfig, same issue. Here is ldd output... it looks OK to me, it is finding the new libraries I compiled in /usr/local/lib and using the other libraries in /usr % which gnumeric /local/bin/gnumeric % ldd `which gnumeric` linux-gate.so.1 => (0xffffe000) libspreadsheet-1.6.3.so => /usr/local/lib/libspreadsheet-1.6.3.so (0xb7bcb000) libpopt.so.0 => /usr/lib/libpopt.so.0 (0xb7bc3000) libm.so.6 => /lib/tls/libm.so.6 (0xb7ba0000) libc.so.6 => /lib/tls/libc.so.6 (0xb7a84000) libgoffice-1.so.2 => /usr/local/lib/libgoffice-1.so.2 (0xb79a8000) libgnomeui-2.so.0 => /usr/lib/libgnomeui-2.so.0 (0xb791d000) libbonoboui-2.so.0 => /usr/lib/libbonoboui-2.so.0 (0xb78bd000) libgnome-2.so.0 => /usr/lib/libgnome-2.so.0 (0xb78a9000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb75c0000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb7542000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb750a000) libgnomevfs-2.so.0 => /usr/lib/libgnomevfs-2.so.0 (0xb74a8000) libbonobo-2.so.0 => /usr/lib/libbonobo-2.so.0 (0xb744e000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb741a000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7398000) libglade-2.0.so.0 => /usr/lib/libglade-2.0.so.0 (0xb7382000) libgnomeprintui-2-2.so.0 => /usr/lib/libgnomeprintui-2-2.so.0 (0xb7349000) libgnomeprint-2-2.so.0 => /usr/lib/libgnomeprint-2-2.so.0 (0xb72e3000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0xb72da000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0xb72c2000) libgnome-keyring.so.0 => /usr/lib/libgnome-keyring.so.0 (0xb72b7000) libgnomecanvas-2.so.0 => /usr/lib/libgnomecanvas-2.so.0 (0xb728d000) libart_lgpl_2.so.2 => /usr/lib/libart_lgpl_2.so.2 (0xb7277000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb7252000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb7238000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb7222000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb721b000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb71d1000) libgsf-gnome-1.so.114 => /usr/local/lib/libgsf-gnome-1.so.114 (0xb71cc000) libgsf-1.so.114 => /usr/local/lib/libgsf-1.so.114 (0xb719f000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb7080000) libz.so.1 => /usr/lib/libz.so.1 (0xb706e000) libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0xb703b000) libbonobo-activation.so.4 => /usr/lib/libbonobo-activation.so.4 (0xb7027000) libORBit-2.so.0 => /usr/lib/libORBit-2.so.0 (0xb6fd1000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb6fcd000) libdl.so.2 => /lib/tls/libdl.so.2 (0xb6fc8000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb6fc4000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb6fb2000) /lib/ld-linux.so.2 (0xb7f55000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb6f95000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb6eca000) libesd.so.0 => /usr/lib/libesd.so.0 (0xb6ec0000) libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0xb6e9a000) libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0xb6e97000) libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0xb6e8f000) libXinerama.so.1 => /usr/X11R6/lib/libXinerama.so.1 (0xb6e8b000) libfontconfig.so.1 => /usr/X11R6/lib/libfontconfig.so.1 (0xb6e64000) libXcursor.so.1 => /usr/X11R6/lib/libXcursor.so.1 (0xb6e5b000) libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0xb6e53000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0xb6e45000) libXfixes.so.3 => /usr/X11R6/lib/libXfixes.so.3 (0xb6e40000) libssl.so.0 => /usr/lib/libssl.so.0 (0xb6e0e000) libcrypto.so.0 => /usr/lib/libcrypto.so.0 (0xb6d0d000) libhowl.so.0 => /usr/lib/libhowl.so.0 (0xb6be6000) libresolv.so.2 => /lib/tls/libresolv.so.2 (0xb6bd3000) librt.so.1 => /lib/tls/librt.so.1 (0xb6bcb000) libORBitCosNaming-2.so.0 => /usr/lib/libORBitCosNaming-2.so.0 (0xb6bc5000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb6b5b000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb6b2a000) libglitz.so.1 => /usr/lib/libglitz.so.1 (0xb6b04000) libbz2.so.1 => /lib/libbz2.so.1 (0xb6af4000) libasound.so.2 => /usr/lib/libasound.so.2 (0xb6a3b000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0xb6a1b000)
I can replicate the original problem.
Crash fixed in cvs HEAD. The underlying problem remains [and it is that we process too many events when we update the progress bar] and is covered elsewhere. I am not sure what your 1.6.3 problem is but it is likely an installation issue. Try running under gdb and see if it tells us anything.
(In reply to comment #11) > Crash fixed in cvs HEAD. That was fast! > The underlying problem remains [and it is that > we process too many events when we update the progress bar] and is covered > elsewhere. > I am not sure what your 1.6.3 problem is but it is likely an installation > issue. Try running under gdb and see if it tells us anything. Well, I tried it a while ago and it didn't tell me anything, but here goes: (gdb) run Starting program: /usr/local/bin/gnumeric (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1230608704 (LWP 27185)] Reading file:///home/zsd/courses/2213/a.xls Excel 95 Program received signal SIGSEGV, Segmentation fault.
+ Trace 67706
Thread NaN (LWP 27185)