GNOME Bugzilla – Bug 335152
Empty xml files crashed gnumeric
Last modified: 2006-10-17 19:41:58 UTC
Distribution: Gentoo Base System version 1.12.0_pre16 Package: Gnumeric Severity: normal Version: GNOME2.12.3 1.6.x Gnome-Distributor: Gentoo Synopsis: kspread .ods with emty xml files crashed gnumeric Bugzilla-Product: Gnumeric Bugzilla-Component: import/export OOo / OASIS Bugzilla-Version: 1.6.x BugBuddy-GnomeVersion: 2.0 (2.12.1) Description: Description of the crash: A particular file that I have which seems to be malformed causes gnumeric to crash. This file was generated by kspread. Steps to reproduce the crash: 1. $ gnumeric path/to/file.ods 2. Reading file:///home/justin/path/to/file.ods (gnumeric:31192): XML-CRITICAL **: Document is empty (gnumeric:31192): XML-CRITICAL **: Start tag expected, '<' not found 3. crash Expected Results: no crash How often does this hapen: Every time I open the file in gnumeric. Additional Information: Three of the files are completely empty. $ ls -lhR .: total 12K drwxr-xr-x 2 justin justin 4.0K Mar 19 12:18 META-INF -rw-r--r-- 1 justin justin 1.2K Mar 19 12:17 content.xml -rw-r--r-- 1 justin justin 1.5K Mar 19 12:06 file.ods -rw-r--r-- 1 justin justin 0 Mar 19 12:17 meta.xml -rw-r--r-- 1 justin justin 0 Mar 19 12:17 settings.xml -rw-r--r-- 1 justin justin 0 Mar 19 12:17 styles.xml ./META-INF: total 4.0K -rw-r--r-- 1 justin justin 756 Mar 19 12:17 manifest.xml Debugging Information: Backtrace was generated from '/usr/bin/gnumeric' (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (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) (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) (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 47300859253472 (LWP 31014)] [New Thread 1074272592 (LWP 31023)] [New Thread 1074006352 (LWP 31017)] 0x000000372540ce49 in waitpid () from /lib/libpthread.so.0
+ Trace 67058
Thread 1 (Thread 47300859253472 (LWP 31014))
Could you attach a sample file, please?
This looks like a libxml bug -- tossing over there. The "end document" handler is being called without the "start document" handler having been called. I am installing a simple workaround in libgsf. Breakpoint 3, gsf_xml_in_end_document (state=0xffbee1c0) at gsf-libxml.c:724 724 g_string_free (state->pub.content, TRUE); (gdb) where
+ Trace 67073
> The "end document" handler is being called without the "start document" > handler having been called. Hum ... client code should really not crash because of this. paphio:~/XML -> touch empty paphio:~/XML -> xmllint --sax empty SAX.setDocumentLocator() SAX.error: Document is empty SAX.error: Start tag expected, '<' not found SAX.endDocument() paphio:~/XML -> true it's a bit weird, but I'm not sure it should be changed, for example setDocumentLocator() could lead to some allocation. The behaviour of libxml2 didn't chnaged over this for years, apps should definitely be fixed, but I'm not sure it's a good idea to change libxml2 behaviour. Daniel
I don't have strong feelings about this being or not being something to fix. If you decide against it, however, a nice fat comment would be nice.