GNOME Bugzilla – Bug 325142
Crash while saving .gnumeric file
Last modified: 2007-01-06 12:47:33 UTC
They open up the different formats correctly, but when keeping them in another format, Gnumeric gives error message and he/she closes the application without saving the changes. I use WinXP SP2 Micro AMD Athlon XP 2.0 RAM 256 Mother integrated PCChips Se puede enviar en español?? Thanks
Could you please give us a sample file that causes problems? Also, what format are you trying to save in?
The forms with those that I have problems cannot be sent because they have but of 1Mb of size. Can the size be the cause of the problem?
Size is probably not an issue, but it is easy to check: delete large areas with numbers or text and retry. (Be careful not to overwrite your original, of course.) What format are you trying to save as? My guess would be that there is some sheet object in the file -- some graph type, for example -- that we have a problem with.
Is it a Win32 only bug or not?
I only have installed winXP It doesn't use it in Linux because it doesn't still install it
my disk is fat32 formated no ntfs
Created attachment 58007 [details] Error message
Created attachment 58009 [details] Error message for microsoft
Comment on attachment 58007 [details] Error message This message appears when I erase the image and intent save
Close as incomplete?
Created attachment 76702 [details] test file which cannot be saved in gnumeric format To make gnumeric crash (on WinXP), just open this file and try to save it as a gnumeric file.
I guess I have the same issue like described in the original bug-report. However I am not sure since there is only little information. I use Gnumeric 1.7.1 Build 1 like provided on the Gnumeric homepage on WinXP. The description of the uploaded testfile says it all: The file can be opened/modified and saved in the original .xls format. However saving the file in Gnumeric format leads to a crash. I will also attach the error-report. Thanks a lot for Gnumeric!
Created attachment 76703 [details] error-report related to test.xls-file.
Confirmed, same problem on Gnumeric 1.7.2 under Linux. I was saving a .XLS file as .gnumeric, and the program crashed without saving. Reproducible. I'm compiling 1.7.5 now to check if the bug is still present.
Just tested it in Gnumeric 1.7.5 and yes, the program still crashes when saving from an .xls file as .gnumeric.
I like reproducability. Daniel: could you please try running under gdb: gdb `which gnumeric` run # do whatever it takes to provoke crash where # that should print a stack trace -- attach it here quit
Reading file:///home/daniel/Documents/old.papers/unb/a5%20lesion%20size%20and%20history.xls (no debugging symbols found) (no debugging symbols found) Excel 97 + (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) ** (/usr/bin/gnumeric:18831): CRITICAL **: xl_chart_read_dataformat: assertion `series_index < s->series->len' failed Writing file:///home/daniel/Documents/old.papers/unb/a5%20lesion%20size%20and%20history%20work.gnumeric ** (/usr/bin/gnumeric:18831): CRITICAL **: gsf_value_get_docprop_vector: assertion `VAL_IS_GSF_DOCPROP_VECTOR (value)' failed Program received signal SIGSEGV, Segmentation fault. 0xb75e3794 in gsf_opendoc_metadata_write () from /usr/lib/libgsf-1.so.114 (gdb)
Almost! You missed the important "where" command after the crash.
Crash reproduced. No further info currently needed.
Aha. This was fixed in current code: 2006-10-25 Jody Goldberg <jody@gnome.org> * gsf/gsf-opendoc-utils.c (meta_write_props) : clean up the code to handle missing values and invalid properties. That explains why we couldn't reproduce with the sample file from comment 11. The fix is in libgsf 1.14.3 and will eventually be propagated.
This is just to confirm that the crash doesn't happen any more with the test file from comment 11 using the newest 1.7.6 build for win32 on XP. Thanks a lot.