GNOME Bugzilla – Bug 703308
Segfault on exit after converting an xlsx file to xls
Last modified: 2013-07-03 03:34:40 UTC
Segfault on exit after converting an xlsx file to xls. Git versions of glib, goffice, gnumeric, libgsf and libxml2. Test case: http://www.canadianelectroniclibrary.ca/collateral/CELPublishersCollection.xlsx Backtrace from "ssconvert CELPublishersCollection.xlsx /tmp/out.xls". Crashes with gnumeric too. Program received signal SIGSEGV, Segmentation fault. 0x00007ffff78d5f4c in invalidate_name (nexpr=0x3b6dca0, sheet=0x756230) at dependent.c:2433 2433 : nexpr->pos.wb->during_destruction; (gdb) bt
+ Trace 232169
-- Juha Kylmänen Research Assistant, OUSPG
Note: If I open this file in Gnumeric and try to save it as odf I get a few: ** (/home/aguelzow/gnumeric/bin/gnumeric:21979): WARNING **: Strange size issue in internal_style_list saving also takes very long, but does not crash.
Running the suggested ssconvert I see the same ** (/home/aguelzow/gnumeric/bin/ssconvert:29735): WARNING **: Strange size issue in internal_style_list but also a few ** (/home/aguelzow/gnumeric/bin/ssconvert:29735): CRITICAL **: expr_name_remove: assertion `nexpr->scope != NULL' failed then W Some content will be lost when saving. This format only supports 256 columns, and this workbook has 16383 and finally the above crash with (gdb) p nexpr->pos $2 = {eval = {col = 0, row = 0}, sheet = 0x0, wb = 0x0}
Andreas: I don't see the "strange size" issue. Stack trace? Here's the first valgrind event, the null pointer dereference: ==6492== Invalid read of size 4 ==6492== at 0x4EE1B2C: handle_referencing_names.isra.11 (dependent.c:2433) ==6492== by 0x4EE21CB: do_deps_destroy (dependent.c:2612) ==6492== by 0x4EE3384: dependents_workbook_destroy (dependent.c:2777) ==6492== by 0x4F8EBE1: workbook_dispose (workbook.c:139) ==6492== by 0x594A4A3: g_object_unref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.0) ==6492== by 0x403A26: convert (ssconvert.c:792) ==6492== by 0x40347A: main (ssconvert.c:855) ==6492== Address 0xd8 is not stack'd, malloc'd or (recently) free'd
Breakpoint 1 (g_log) pending. (gdb) run Starting program: /home/aguelzow/gnumeric/bin/ssconvert Downloads/CELPublishersCollection.xlsx Downloads/CELPublishersCollection.xls [Thread debugging using libthread_db enabled] warning: the debug information found in "/usr/lib/debug//usr/lib/libxml2.so.2.7.8" does not match "/usr/lib/libxml2.so.2" (CRC mismatch). warning: the debug information found in "/usr/lib/debug/usr/lib/libxml2.so.2.7.8" does not match "/usr/lib/libxml2.so.2" (CRC mismatch). [New Thread 0xb64a4b70 (LWP 26142)] [New Thread 0xb5ca3b70 (LWP 26143)] Using exporter Gnumeric_Excel:excel_biff8 Unexpected element 'protectedRange' in state : worksheet -> protectedRanges Unexpected element 'protectedRange' in state : worksheet -> protectedRanges Unexpected element 'protectedRange' in state : worksheet -> protectedRanges Breakpoint 1, 0xb795e0a0 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0 (gdb) bt
+ Trace 232182
---Type <return> to continue, or q <return> to quit---q output=0xce4eQuit (gdb) c Continuing. ** (/home/aguelzow/gnumeric/bin/ssconvert:26034): WARNING **: Strange size issue in internal_style_list
after seeing the above four times: Breakpoint 1, 0xb795e0a0 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0 (gdb) bt
+ Trace 232183
---Type <return> to continue, or q <return> to quit---q output=0xce4eQuit (gdb) c Continuing. ** (/home/aguelzow/gnumeric/bin/ssconvert:26034): CRITICAL **: expr_name_remove: assertion `nexpr->scope != NULL' failed
Crash fixed.
At the time of the "strange size", what values do you have for data.area sheet_area range_height (r) range_width (r) ? (This might just be overflow in multiplication.)
Breakpoint 1, 0xb795e0a0 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0 (gdb) bt
+ Trace 232184
Breakpoint 2 at 0xb7dc5027: file sheet-style.c, line 2830. (gdb) c Continuing. ** (/home/aguelzow/gnumeric/bin/ssconvert:1770): WARNING **: Strange size issue in internal_style_list Breakpoint 2, internal_style_list (sheet=0x8508010, r=0xbfffe7d8, style_equal=0xb7dc5270 <style_hlink_equal>, style_filter=0xb7dc52aa <style_hlink_filter>) at sheet-style.c:2830 2830 for (ui = 0; ui < data.accum->len; ui++) { (gdb) p data.area $1 = 5 (gdb) p sheet_area $2 = 0 (gdb) p range_height(r) $3 = 1048576 (gdb) p range_width(r) $4 = 16384 (gdb) p *r $5 = {start = {col = 0, row = 0}, end = {col = 16383, row = 1048575}} (gdb)
Yup, that's integer overflow for H*W. That range is really, really big. I think this should be fixed now.
Yes, this seems to work fine now without any warnings (except the expected warning re potential loss of data since te xlsx sheets are bigger than xls can handle.) This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.