After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 350644 - Crash while reading an empty meta.xml or styles.xml file
Crash while reading an empty meta.xml or styles.xml file
Status: RESOLVED FIXED
Product: libgsf
Classification: Core
Component: General
1.14.x
Other Linux
: Normal major
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2006-08-09 21:14 UTC by sum1
Modified: 2006-09-24 18:21 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14

Attachments
proposed patch (952 bytes, patch)
2006-08-09 21:15 UTC, sum1 		rejected Details | Review
sample ods file (2.24 KB, application/x-vnd.oasis.opendocument.spreadsheet)
2006-08-10 14:39 UTC, sum1 		  Details

Description sum1 2006-08-09 21:14:04 UTC 
Gnumeric CVS-HEAD, FC5.

Steps to reproduce:
- Save an empty workbook as a .ods file
- Attempt to reopen the saved file

Backtrace:
Program received signal SIGSEGV, Segmentation fault.

+ Trace 70148

Thread NaN (LWP 9201)

  • #0 g_hash_table_lookup_extended
    from /usr/lib/libglib-2.0.so.0
  • #1 g_hash_table_destroy
    from /usr/lib/libglib-2.0.so.0
  • #2 gsf_xml_in_doc_free
    from /usr/lib/libgsf-1.so.113
  • #3 xmlParseDocument
    from /usr/lib/libxml2.so.2
  • #4 gsf_xml_in_doc_parse
    from /usr/lib/libgsf-1.so.113
  • #5 gsf_opendoc_metadata_read
    from /usr/lib/libgsf-1.so.113
  • #6 openoffice_file_open
    at openoffice-read.c line 2458
  • #7 go_plugin_loader_module_func_file_open
    at go-plugin-loader-module.c line 239
  • #8 go_plugin_file_opener_open
    at go-plugin-service.c line 500
  • #9 go_file_opener_open
    at file.c line 289
  • #10 wb_view_new_from_input
    at workbook-view.c line 1045
  • #11 wb_view_new_from_uri
    at workbook-view.c line 1096
  • #12 gui_file_read
    at gui-file.c line 163
  • #13 cb_file_history_activate
    at wbc-gtk.c line 771
  • #14 g_cclosure_marshal_VOID__VOID
    from /usr/lib/libgobject-2.0.so.0
  • #15 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #16 g_signal_override_class_closure
    from /usr/lib/libgobject-2.0.so.0
  • #17 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #18 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0 






Comment 1


sum1





          2006-08-09 21:15:36 UTC
        



Created attachment 70585 [details] [review]
proposed patch

Adds two gsf_input_size() checks.






Comment 2


Andreas J. Guelzow





          2006-08-09 23:05:12 UTC
        



Hmm, while these tests are probably useful, the real problem is probably that those files should not be empty!






Comment 3


sum1





          2006-08-09 23:16:20 UTC
        



I should clarify that the steps in comment 0 will only produce an empty meta.xml file. I added the styles.xml check for overall robustness because Gnumeric will crash if you have an empty styles.xml file - I'm just not sure how such a situation would arise.






Comment 4


Andreas J. Guelzow





          2006-08-09 23:23:14 UTC
        



Is this from a recent cvs?  I cannot replicate this problem but seem to recall to have fixed these empty files a short while ago.






Comment 5


sum1





          2006-08-10 14:37:43 UTC
        



Yes, it's the latest CVS (i.e. it includes the "2006-08-09 Eduardo Lima" commit). I see the same behavior after running 'make clean' and 'make uninstall', for what it's worth.






Comment 6


sum1





          2006-08-10 14:39:50 UTC
        



Created attachment 70650 [details]
sample ods file

This is the file that's saved after following the steps in comment 0.






Comment 7


Andreas J. Guelzow





          2006-08-10 22:51:21 UTC
        



With current gnumeric CVS _and_ current libgsf CVS neither meta.xml nor styles.xml is empty. That's why I don't see the crash on empty files I saved. Your libgsf is likely not 100% up-to-date.

In any case I will be committing your patch but we should also have libgsf fixed to avoid any such crash for other programs that might use libgsf.






Comment 8


Andreas J. Guelzow





          2006-08-11 14:36:18 UTC
        



Comment on attachment 70585 [details] [review]
proposed patch

This does not really fix the originally crash which happened in libgsf but avoids unnecessary work (and as a cosequence prevents teh crash from occuring).






Comment 9


Jody Goldberg





          2006-09-24 00:36:15 UTC
        



I can not replicate that crash with libgsf HEAD.
Those tests should not be necessary, and I'd rather remove them.

The backtrace you list looks like it's a crash in gsf rather than gnumeric code.
Can you replicate with current gsf ?






Comment 10


Jody Goldberg





          2006-09-24 01:26:48 UTC
        



patch has been reverted.






Comment 11


sum1





          2006-09-24 02:00:00 UTC
        



(In reply to comment #9)
> I can not replicate that crash with libgsf HEAD.
> Those tests should not be necessary, and I'd rather remove them.
> 
> The backtrace you list looks like it's a crash in gsf rather than gnumeric
> code.
> Can you replicate with current gsf ?
> 

I can't reproduce with libgsf 1.14.1. When I filed this bug, I had whichever version was "current" in the FC5 repositories (from the backtrace, it looks like a .13 version: /usr/lib/libgsf-1.so.113).






Comment 12


Jody Goldberg





          2006-09-24 18:21:29 UTC
        



Ok.  I've double checked that 1.14.2 will not have a problem with 0 sized xml.