GNOME Bugzilla – Bug 705913
gnumeric is unable to open this .gnumeric file
Last modified: 2013-08-17 08:29:02 UTC
See attached file, created with a previous version of gnumeric
The file is here: https://docs.google.com/file/d/0BzX8dPORePBsNFBGc1p4bTRiOEU/edit?usp=sharing
342 color = g_new0 (GOColor, max); 343 if (max < 2) 344 color[0] = GO_COLOR_WHITE; (gdb) p max $1 = 0
+ Trace 232379
Fixed crash, but now getting: Leaking GOFormat at 0xb5bd90 [General].
==9112== 80 bytes in 1 blocks are definitely lost in loss record 9,448 of 13,383 ==9112== at 0x4C2CD7B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==9112== by 0x62FCCF0: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.0) ==9112== by 0x22DB0CC3: gog_xyz_plot_get_x_vals (gog-xyz.c:122) ==9112== by 0x22DBA94E: gog_xyz_surface_plot_build_matrix (gog-xyz-surface.c:302) ==9112== by 0x22DB0E3A: gog_xyz_plot_update_3d (gog-xyz.c:80) ==9112== by 0x540A237: gog_axis_calc_ticks (gog-axis.c:2024) ==9112== by 0x540AA33: gog_axis_update (gog-axis.c:2503) ==9112== by 0x540ABBB: gog_axis_dim_changed (gog-axis.c:3172) ... ==9112== 80 bytes in 1 blocks are definitely lost in loss record 9,449 of 13,383 ==9112== at 0x4C2CD7B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==9112== by 0x62FCCF0: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.0) ==9112== by 0x22DB0B63: gog_xyz_plot_get_y_vals (gog-xyz.c:146) ==9112== by 0x22DBAA0C: gog_xyz_surface_plot_build_matrix (gog-xyz-surface.c:309) ==9112== by 0x22DB0E3A: gog_xyz_plot_update_3d (gog-xyz.c:80) ==9112== by 0x540A237: gog_axis_calc_ticks (gog-axis.c:2024) ==9112== by 0x540AA33: gog_axis_update (gog-axis.c:2503) ==9112== by 0x540ABBB: gog_axis_dim_changed (gog-axis.c:3172) ... ==9112== 80 bytes in 1 blocks are definitely lost in loss record 9,450 of 13,383 ==9112== at 0x4C2CD7B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==9112== by 0x62FCCF0: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.0) ==9112== by 0x22DB0CC3: gog_xyz_plot_get_x_vals (gog-xyz.c:122) ==9112== by 0x22DBA94E: gog_xyz_surface_plot_build_matrix (gog-xyz-surface.c:302) ==9112== by 0x22DB8BA5: gog_xyz_surface_plot_update (gog-xyz-surface.c:561) ==9112== by 0x53F5D87: gog_object_update (gog-object.c:1596) ==9112== by 0x53F5D27: gog_object_update (gog-object.c:1589) ==9112== by 0x53F5D27: gog_object_update (gog-object.c:1589) ==9112== by 0x53FD4F5: cb_graph_idle (gog-graph.c:848) ...
gog_xyz_plot_update_3d is called at least 9 times when ->plotted_data isn't NULL. That looks like a leak.
I fixed the leaks in gog-xyz.c, but we still have: Leaking GOFormat at 0x160a3d60 [General]. and: ==5029== 56 (40 direct, 16 indirect) bytes in 1 blocks are definitely lost in loss record 6,340 of 12,873 ==5029== at 0x4C29C64: calloc (vg_replace_malloc.c:593) ==5029== by 0x7DC9998: g_malloc0 (gmem.c:189) ==5029== by 0x5448AE3: go_format_create (go-format.c:1313) ==5029== by 0x544BF26: go_format_parse_sequential (go-format.c:1671) ==5029== by 0x5452CBE: go_format_new_from_XL (go-format.c:2357) ==5029== by 0x5452985: go_format_general (go-format.c:6508) ==5029== by 0x4F23F22: gnm_style_new_default (mstyle.c:607) ==5029== by 0x4F7319C: sheet_style_init_size (sheet-style.c:677) ==5029== by 0x4F462EC: gnm_sheet_constructed (sheet.c:686) ==5029== by 0x7B42454: g_object_newv (gobject.c:1747) ==5029== by 0x7B427A5: g_object_new_valist (gobject.c:1836) ==5029== by 0x7B42B13: g_object_new (gobject.c:1551) ==5029== by 0x4F3CC08: sheet_new_with_type (sheet.c:1417) ==5029== by 0x4FA3582: xml_sax_wb_sheetname (xml-sax-read.c:576) ==5029== by 0x571A5E8: gsf_xml_in_end_element (gsf-libxml.c:845) ==5029== by 0x59934CC: ??? (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.1) ==5029== by 0x5999A7A: xmlParseElement (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.1) ==5029== by 0x5998F87: xmlParseContent (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.1) ==5029== by 0x5999822: xmlParseElement (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.1) ==5029== by 0x5998F87: xmlParseContent (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.1) ==5029== by 0x5999822: xmlParseElement (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.1) ==5029== by 0x5999E49: xmlParseDocument (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.1) ==5029== by 0x571B343: gsf_xml_in_doc_parse (gsf-libxml.c:1290) ==5029== by 0x4FA5C34: read_file_common (xml-sax-read.c:3359) ==5029== by 0x4FA5F7B: gnm_xml_file_open (xml-sax-read.c:3488) I also see a coule of invalid read: ==5029== Invalid read of size 8 ==5029== at 0x4EDE1C0: unlink_single_dep (dependent.c:897) ==5029== by 0x4EDEBAE: link_unlink_expr_dep (dependent.c:924) ==5029== by 0x4EDF4EF: dependent_unlink (dependent.c:1537) ==5029== by 0x4EDF674: dependent_set_expr (dependent.c:412) ==5029== by 0x4EDF765: dependent_managed_set_expr (dependent.c:1306) ==5029== by 0x502BEA6: gnm_solver_param_finalize (gnm-solver.c:678) ==5029== by 0x7B408D9: g_object_unref (gobject.c:3024) ==5029== by 0x4F42E3A: gnm_sheet_finalize (sheet.c:4537) ==5029== by 0x7B408D9: g_object_unref (gobject.c:3024) ==5029== by 0x4F8950D: workbook_sheet_delete (workbook.c:1104) ==5029== by 0x4F8A00F: workbook_dispose (workbook.c:157) ==5029== by 0x7B4084B: g_object_unref (gobject.c:2987) ==5029== by 0x4F982AE: wbc_gtk_close (wbc-gtk.c:1811) ==5029== by 0x62440ED: _gtk_marshal_BOOLEAN__BOXEDv (gtkmarshalers.c:130) ==5029== by 0x7B3C156: _g_closure_invoke_va (gclosure.c:840) ==5029== by 0x7B54247: g_signal_emit_valist (gsignal.c:3234) ==5029== by 0x7B54F31: g_signal_emit (gsignal.c:3384) ==5029== by 0x6364373: gtk_widget_event_internal (gtkwidget.c:6714) ==5029== by 0x6243E28: gtk_main_do_event (gtkmain.c:1596) ==5029== by 0x67D6DA1: gdk_event_source_dispatch (gdkeventsource.c:364) ==5029== by 0x7DC3EA5: g_main_context_dispatch (gmain.c:3054) ==5029== by 0x7DC41F7: g_main_context_iterate.isra.22 (gmain.c:3701) ==5029== by 0x7DC45F9: g_main_loop_run (gmain.c:3895) ==5029== by 0x624318C: gtk_main (gtkmain.c:1156) ==5029== by 0x403695: main (main-application.c:383) ==5029== Address 0x160ab840 is 400 bytes inside a block of size 488 free'd ==5029== at 0x4C2AB1C: free (vg_replace_malloc.c:446) ==5029== by 0x7B5C318: g_type_free_instance (gtype.c:1962) ==5029== by 0x4F8950D: workbook_sheet_delete (workbook.c:1104) ==5029== by 0x4F8A00F: workbook_dispose (workbook.c:157) ==5029== by 0x7B4084B: g_object_unref (gobject.c:2987) ==5029== by 0x4F982AE: wbc_gtk_close (wbc-gtk.c:1811) ==5029== by 0x62440ED: _gtk_marshal_BOOLEAN__BOXEDv (gtkmarshalers.c:130) ==5029== by 0x7B3C156: _g_closure_invoke_va (gclosure.c:840) ==5029== by 0x7B54247: g_signal_emit_valist (gsignal.c:3234) ==5029== by 0x7B54F31: g_signal_emit (gsignal.c:3384) ==5029== by 0x6364373: gtk_widget_event_internal (gtkwidget.c:6714) ==5029== by 0x6243E28: gtk_main_do_event (gtkmain.c:1596) ==5029== by 0x67D6DA1: gdk_event_source_dispatch (gdkeventsource.c:364) ==5029== by 0x7DC3EA5: g_main_context_dispatch (gmain.c:3054) ==5029== by 0x7DC41F7: g_main_context_iterate.isra.22 (gmain.c:3701) ==5029== by 0x7DC45F9: g_main_loop_run (gmain.c:3895) ==5029== by 0x624318C: gtk_main (gtkmain.c:1156) ==5029== by 0x403695: main (main-application.c:383) ==5029== ==5029== Invalid read of size 8 ==5029== at 0x4EDE1D4: unlink_single_dep (dependent.c:900) ==5029== by 0x4EDEBAE: link_unlink_expr_dep (dependent.c:924) ==5029== by 0x4EDF4EF: dependent_unlink (dependent.c:1537) ==5029== by 0x4EDF674: dependent_set_expr (dependent.c:412) ==5029== by 0x4EDF765: dependent_managed_set_expr (dependent.c:1306) ==5029== by 0x502BEA6: gnm_solver_param_finalize (gnm-solver.c:678) ==5029== by 0x7B408D9: g_object_unref (gobject.c:3024) ==5029== by 0x4F42E3A: gnm_sheet_finalize (sheet.c:4537) ==5029== by 0x7B408D9: g_object_unref (gobject.c:3024) ==5029== by 0x4F8950D: workbook_sheet_delete (workbook.c:1104) ==5029== by 0x4F8A00F: workbook_dispose (workbook.c:157) ==5029== by 0x7B4084B: g_object_unref (gobject.c:2987) ==5029== by 0x4F982AE: wbc_gtk_close (wbc-gtk.c:1811) ==5029== by 0x62440ED: _gtk_marshal_BOOLEAN__BOXEDv (gtkmarshalers.c:130) ==5029== by 0x7B3C156: _g_closure_invoke_va (gclosure.c:840) ==5029== by 0x7B54247: g_signal_emit_valist (gsignal.c:3234) ==5029== by 0x7B54F31: g_signal_emit (gsignal.c:3384) ==5029== by 0x6364373: gtk_widget_event_internal (gtkwidget.c:6714) ==5029== by 0x6243E28: gtk_main_do_event (gtkmain.c:1596) ==5029== by 0x67D6DA1: gdk_event_source_dispatch (gdkeventsource.c:364) ==5029== by 0x7DC3EA5: g_main_context_dispatch (gmain.c:3054) ==5029== by 0x7DC41F7: g_main_context_iterate.isra.22 (gmain.c:3701) ==5029== by 0x7DC45F9: g_main_loop_run (gmain.c:3895) ==5029== by 0x624318C: gtk_main (gtkmain.c:1156) ==5029== by 0x403695: main (main-application.c:383) ==5029== Address 0x160ab6d0 is 32 bytes inside a block of size 488 free'd ==5029== at 0x4C2AB1C: free (vg_replace_malloc.c:446) ==5029== by 0x7B5C318: g_type_free_instance (gtype.c:1962) ==5029== by 0x4F8950D: workbook_sheet_delete (workbook.c:1104) ==5029== by 0x4F8A00F: workbook_dispose (workbook.c:157) ==5029== by 0x7B4084B: g_object_unref (gobject.c:2987) ==5029== by 0x4F982AE: wbc_gtk_close (wbc-gtk.c:1811) ==5029== by 0x62440ED: _gtk_marshal_BOOLEAN__BOXEDv (gtkmarshalers.c:130) ==5029== by 0x7B3C156: _g_closure_invoke_va (gclosure.c:840) ==5029== by 0x7B54247: g_signal_emit_valist (gsignal.c:3234) ==5029== by 0x7B54F31: g_signal_emit (gsignal.c:3384) ==5029== by 0x6364373: gtk_widget_event_internal (gtkwidget.c:6714) ==5029== by 0x6243E28: gtk_main_do_event (gtkmain.c:1596) ==5029== by 0x67D6DA1: gdk_event_source_dispatch (gdkeventsource.c:364) ==5029== by 0x7DC3EA5: g_main_context_dispatch (gmain.c:3054) ==5029== by 0x7DC41F7: g_main_context_iterate.isra.22 (gmain.c:3701) ==5029== by 0x7DC45F9: g_main_loop_run (gmain.c:3895) ==5029== by 0x624318C: gtk_main (gtkmain.c:1156) ==5029== by 0x403695: main (main-application.c:383)
The remaining valgrind leak says the same as the leak message. Formats are ref-counted so knowning who allocated the format in the first place unfortunately doesn't help. The FMR looks bad. Really bad.
FMR fixed.
11:01 <@gmorten> gog_xyz_plot_get_x_vals, gog-xyz.c, line 125 11:01 <@gmorten> shouldn't that call to go_data_vector_val_new have g_free as a destroy function? 11:02 <@gmorten> (and ditto gog_xyz_plot_get_y_vals, of course)
this is fixed, as well as an uninitialized data issue in staircase interpolation. Now trying to simplify the file, but gnumeric crashes on savig. To reproduce, manage sheets, select last sheet, remove sheets until the last one is "para" and save: boom. Getting: ** (gnumeric:17864): CRITICAL **: go_doc_get_uri: assertion `GO_IS_DOC (doc)' failed Segfault
GOFormat leak fixed.
This took a _long_ _long_ time. I didn't follow your way completely, but we're clearly holding on to some sheet we shouldn't. ==15837== at 0x4F36CA1: cellref_as_string (parse-util.c:278) ==15837== by 0x4EEDE4A: do_expr_as_string (expr.c:1746) ==15837== by 0x4EEDF39: do_expr_as_string (expr.c:1731) ==15837== by 0x4EEDAC4: gnm_expr_list_as_string (expr.c:2810) ==15837== by 0x4EEDDB7: do_expr_as_string (expr.c:1738) ==15837== by 0x4EEDD4D: do_expr_as_string (expr.c:1691) ==15837== by 0x4EEDD95: do_expr_as_string (expr.c:1717) ==15837== by 0x4EEDAC4: gnm_expr_list_as_string (expr.c:2810) ==15837== by 0x4EEDDB7: do_expr_as_string (expr.c:1738) ==15837== by 0x4FBADA2: xml_write_cell_and_position (xml-sax-write.c:887) ==15837== by 0x4FBAEA2: cb_write_cell (xml-sax-write.c:904) ==15837== by 0x4F4C23B: sheet_foreach_cell_in_range (sheet.c:3932) ==15837== by 0x4FBCDD8: gnm_xml_file_save_full.isra.23 (xml-sax-write.c:912) ==15837== by 0x4F9AD81: wbv_save_to_output (workbook-view.c:1055) ==15837== by 0x4F9AED7: wb_view_save_to_uri (workbook-view.c:1092) ==15837== by 0x4F9B32A: wb_view_save (workbook-view.c:1187) ==15837== by 0x4F0B354: gui_file_save (gui-file.c:766) ==15837== by 0x876A6FF: g_closure_invoke (in /usr/lib64/libgobject-2.0.so.0.3200.4) ==15837== by 0x877B76F: ??? (in /usr/lib64/libgobject-2.0.so.0.3200.4) ==15837== by 0x87836DB: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.3200.4) ==15837== by 0x8783871: g_signal_emit (in /usr/lib64/libgobject-2.0.so.0.3200.4) ==15837== by 0x6DD7D82: ??? (in /usr/lib64/libgtk-3.so.0.400.4) ==15837== by 0x6F94818: ??? (in /usr/lib64/libgtk-3.so.0.400.4) ==15837== by 0x876A9C6: ??? (in /usr/lib64/libgobject-2.0.so.0.3200.4) ==15837== by 0x8783025: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.3200.4) ==15837== by 0x8783871: g_signal_emit (in /usr/lib64/libgobject-2.0.so.0.3200.4) ==15837== by 0x6DFDA97: ??? (in /usr/lib64/libgtk-3.so.0.400.4) ==15837== by 0x876A6FF: g_closure_invoke (in /usr/lib64/libgobject-2.0.so.0.3200.4) ==15837== by 0x877B092: ??? (in /usr/lib64/libgobject-2.0.so.0.3200.4) ==15837== by 0x87836DB: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.3200.4) ==15837== by 0x8783871: g_signal_emit (in /usr/lib64/libgobject-2.0.so.0.3200.4) ==15837== by 0x6DFBDB2: ??? (in /usr/lib64/libgtk-3.so.0.400.4) ==15837== by 0x6EBD0DE: ??? (in /usr/lib64/libgtk-3.so.0.400.4) ==15837== by 0x876A9C6: ??? (in /usr/lib64/libgobject-2.0.so.0.3200.4) ==15837== by 0x8783025: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.3200.4) ==15837== by 0x8783871: g_signal_emit (in /usr/lib64/libgobject-2.0.so.0.3200.4) ==15837== by 0x6FE537D: ??? (in /usr/lib64/libgtk-3.so.0.400.4) ==15837== by 0x6EBB0A4: ??? (in /usr/lib64/libgtk-3.so.0.400.4) ==15837== by 0x6EBCCB2: gtk_main_do_event (in /usr/lib64/libgtk-3.so.0.400.4) ==15837== by 0x740E621: ??? (in /usr/lib64/libgdk-3.so.0.400.4) ==15837== Address 0x14f73840 is not stack'd, malloc'd or (recently) free'd
The crash occurs when writing 'Vostok-IceCore-data'!F3 which references sheet Omega-space. The crash can be provoked by just removing depth_ie, then Omega-space, then TODO. (The last one just ends up clearing the undo queue.) The select 'Vostok-IceCore-data'!F3. Removing depth_ie and then Omega-space shows that 'Vostok-IceCore-data'!F3 has a reference to Omega-space which should have been #REF! This doesn't crash because Omega-space still lives in the undo world.
Hmm... I think I may have had an old copy of that sheet lying around. The file linked to in this bug doesn't have a Vostok-IceCore-data sheet. I suspect the problem is a variant of the one described above, though.
For the dependency problem see bug 706095. This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.
The file still does not open using git gnumeric from a few minutes ago. The error message is: gnumeric: symbol lookup error: /usr/local/lib/goffice/0.10.5/plugins/plot_surface/surface.so: undefined symbol: gog_matrix_plot_register_type
That looks like an installation problem, not anything related to this file. I would suggest trying make clean make sudo make install to see if that clears up things.
Your solution does not work. Moreover, the problem only occurs with this particular file, not with other files I have tested.
What it is saying is that it cannot load the surface plugin. You will have that error for any file that contains a 3d surface plot. Any error messages or warnings during the compilation of the plugins?
This is the output of 'make install' related to surface: Making install in plot_surface make[2]: entrant dans le répertoire « /usr/local/goffice/plugins/plot_surface » make install-am make[3]: entrant dans le répertoire « /usr/local/goffice/plugins/plot_surface » make[4]: entrant dans le répertoire « /usr/local/goffice/plugins/plot_surface » make[4]: Rien à faire pour « install-exec-am ». /bin/mkdir -p '/usr/local/lib/goffice/0.10.5/plugins/plot_surface' /bin/bash ../../libtool --mode=install /usr/bin/install -c surface.la '/usr/local/lib/goffice/0.10.5/plugins/plot_surface' libtool: install: warning: relinking `surface.la' libtool: install: (cd /usr/local/goffice/plugins/plot_surface; /bin/bash /usr/local/goffice/libtool --silent --tag CC --mode=relink gcc -g -O2 -Wall -Wstrict-prototypes -Wnested-externs -Werror=missing-prototypes -Werror=implicit-function-declaration -Werror=pointer-arith -Werror=init-self -Werror=format-security -Werror=format=2 -Werror=missing-include-dirs -Wsign-compare -Wpointer-arith -Wchar-subscripts -Wwrite-strings -Wdeclaration-after-statement -Wnested-externs -Wmissing-noreturn -Werror=missing-prototypes -Werror=nested-externs -Werror=implicit-function-declaration -Wmissing-declarations -Wno-pointer-sign -Werror=format-security -Wstrict-prototypes -module -avoid-version -no-undefined -o surface.la -rpath /usr/local/lib/goffice/0.10.5/plugins/plot_surface gog-xyz.lo gog-contour.lo gog-surface.lo gog-xyz-surface.lo xl-surface.lo gog-xyz-prefs.lo gog-xyz-surface-prefs.lo ../../goffice/libgoffice-0.10.la -Wl,--export-dynamic -pthread -L/usr/local/lib -lgmodule-2.0 -lgsf-1 -lxml2 -lrsvg-2 -lm -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0 -lglib-2.0 -lm ) libtool: install: /usr/bin/install -c .libs/surface.soT /usr/local/lib/goffice/0.10.5/plugins/plot_surface/surface.so libtool: install: /usr/bin/install -c .libs/surface.lai /usr/local/lib/goffice/0.10.5/plugins/plot_surface/surface.la libtool: finish: PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/sbin" ldconfig -n /usr/local/lib/goffice/0.10.5/plugins/plot_surface ---------------------------------------------------------------------- Libraries have been installed in: /usr/local/lib/goffice/0.10.5/plugins/plot_surface If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,-rpath -Wl,LIBDIR' linker flag - have your system administrator add LIBDIR to `/etc/ld.so.conf' See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ---------------------------------------------------------------------- /bin/mkdir -p '/usr/local/lib/goffice/0.10.5/plugins/plot_surface' /usr/bin/install -c -m 644 plugin.xml plot-types.xml '/usr/local/lib/goffice/0.10.5/plugins/plot_surface' make[4]: quittant le répertoire « /usr/local/goffice/plugins/plot_surface » make[3]: quittant le répertoire « /usr/local/goffice/plugins/plot_surface » make[2]: quittant le répertoire « /usr/local/goffice/plugins/plot_surface »
There is no particular warning or error message during the 'make' command.
Your Makefile needs to be updated, run autogen.sh again.
Yes that helps. Note that the scale of the pseudo 3D axis ('Age' tab) has been lost.
(In reply to comment #23) > Yes that helps. > Note that the scale of the pseudo 3D axis ('Age' tab) has been lost. Fixed too.
Note that the scale might be a bit different now for xyz plots.