GNOME Bugzilla – Bug 72706
Nautilus crashes on strlen in xmlparserwarning
Last modified: 2004-12-22 21:47:04 UTC
Running Nautilus on machine with no prexisting .nautilus/bookmarks.xml file causes nautilus to crash with the following stack trace: nautilus --disable-crash-dialog nautilus (pid:10717): Gnome-WARNING **: invalid gnome config path '=/section/key' warning: failed to load external entity "/home/bn128650/.nautilus/bookmarks.xml" warning: file Segmentation Fault(coredump) puncher:/home/bn128650 220 $ file core core: ELF 32-bit MSB core file SPARC Version 1, from 'nautilus' puncher:/home/bn128650 221 $ pstack core core 'core' of 10717: nautilus --disable-crash-dialog ----------------- lwp# 1 / thread# 1 -------------------- fd9b2d38 strlen (fe82e5f8, 0, ffbfd4a8, fda38000, 3ae870, 1) + 80 fda05e7c vsnprintf (3ba988, 96, fe82e5f8, ffbfd58c, 3ae9c8, 5) + 5c fe7485b4 xmlParserWarning (3ae9c8, fe82e5f8, 0, fffffff8, 0, 3c77a9) + 16c fe7995e8 xmlDefaultExternalEntityLoader (0, 0, 3ae9c8, fffffff8, 0, 3aeae9) + 328 fe799894 xmlLoadExternalEntity (0, 0, 3ae9c8, 8, 7, ff00) + 5c fe77dccc xmlCreateFileParserCtxt (0, 1, 2cefc, 0, 69002458, 69002458) + ac fe77ddf0 xmlSAXParseFileWithData (0, 0, 0, 0, fff59d64, 0) + 48 fe77dff4 xmlSAXParseFile (0, 0, 0, ff3b0e64, ff3b0e64, ffbfd824) + 4c fe77e0e0 xmlParseFile (0, ff3f7c38, 3cb, ff1e1348, ff18e334, 1) + 38 ff259e84 local_set_root_property (27dfe8, ff2cdca4, 3b4920, 0, ff191714, 5) + 4c ff25a130 nautilus_link_historical_local_set_link_uri (27dfe8, 3b4920, 3bb662, 0, 81010100, ff00) + 50 ff25aed8 nautilus_link_local_set_link_uri (27dfe8, 3b4920, 0, ffbfda10, ff19a584, 5) + 50 000b7e44 update_link_and_delete_copies (161e14, 0, 3b4920, 0, 7400, ff00) + 11c 000b7f58 update_home_link_and_delete_copies (3aa3f8, 1, b6db0, 3abce0, 0, 0) + 88 000b7130 fm_desktop_icon_view_init (3abce0, 39ff18, 1, 0, 0, 3a5761) + 280 fdcd1c90 g_type_create_instance (3b4ae0, 3a5730, 1, 0, 8, 3b1508) + 2f8 fdca9f08 g_object_constructor (3b4ae0, 2, 3afd88, 0, 0, 3071a0) + 38 fdca9694 g_object_newv (3b4ae0, 0, 0, 1672c8, 0, 0) + 594 fdca98e8 g_object_new_valist (3b4ae0, 0, ffbfddf4, 0, 50, 50) + e0 fdca90c0 g_object_new (3b4ae0, 0, ac, 0, 10109, 0) + e0 0006f6c0 create_object (1b455c, 37ee81, ffbfe11c, ffffffff, 11, 11) + c8 fec50d44 _ORBIT_skel_small_Bonobo_GenericFactory_createObject (1b455c, ffbfdfc8, ffbfdfc0, ffbfe010, ffbfe11c, 6f5f8) + 64 fe8e22d4 ORBit_POAObject_invoke (1e6208, ffbfdfc8, ffbfdfc0, ffbfe010, ffbfe090, ffbfe11c) + 84 fe8eac70 ORBit_OAObject_invoke (1e6208, ffbfdfc8, ffbfdfc0, ffbfe010, ffbfe090, ffbfe11c) + 78 fe8c3350 ORBit_small_invoke_adaptor (1e6208, 254ef0, fec778d8, ffbfe090, ffbfe11c, ffbfe139) + 600 fe8e2b20 ORBit_POAObject_handle_request (1e6208, 258258, 0, 0, 0, 254ef0) + 6a0 fe8e300c ORBit_POA_handle_request (1aa5b0, 254ef0, 254f08, ffffffff, 50, 50) + 1c4 fe8eaa34 ORBit_handle_request (1aa128, 254ef0, ac, 0, 0, 0) + 9c fe8b6f3c giop_connection_handle_input (1e9790, 10, 142bdf4, 0, 0, ffbfe2c0) + 50c feb376f8 linc_connection_io_handler (0, 1, 1e9790, 0, 0, 0) + d8 feb3b7bc linc_source_dispatch (1e8228, feb37620, 1e9790, ffbfe3c0, ff7bc1ac, 0) + 9c fdbe0260 g_main_dispatch (1a81f0, 0, 0, fe870504, fe870504, ffbfe4ac) + 270 fdbe2218 g_main_context_dispatch (1a81f0, c8, 3999a8, 10, 10, 5) + c8 fdbe2978 g_main_context_iterate (1a81f0, 1, 1, 18b230, fe00c39c, 5) + 6b8 fdbe39a0 g_main_loop_run (1f21d0, 1f21d0, ffbfe5bc, 1b4548, 0, 0) + 5c0 fe1996b0 gtk_main (1, 0, 0, 0, 0, 1) + 1c0 0007c268 main (169e30, 169e40, 169e50, 169e64, 169e70, 169e88) + 5c8 0006b318 _start (0, 0, 0, 0, 0, 0) + 108 ----------------- lwp# 2 / thread# 2 -------------------- fe965a34 __lwp_park (253318, fe978b70, 0, 0, fd970200, fe978000) + 14 fe963510 cond_wait (253318, 253300, fd77bec0, fded6000, fdec4e9c, 0) + 14 fe96354c pthread_cond_wait (253318, 253300, fd970200, 0, 0, 0) + 8 febe20bc gnome_vfs_thread_pool_wait_for_work (2532f8, 0, 0, 0, 0, 0) + 7c febe215c thread_entry (2532f8, 0, 0, 0, 0, 0) + 54 fe9658f0 _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 3 / thread# 3 -------------------- fe965a34 __lwp_park (253430, fe978b70, 0, 0, fd970400, fe978000) + 14 fe963510 cond_wait (253430, 253418, fd67bec0, fded6000, fdec4e9c, 1) + 14 fe96354c pthread_cond_wait (253430, 253418, fd970400, 0, 0, 0) + 8 febe20bc gnome_vfs_thread_pool_wait_for_work (253410, 0, 0, 0, 0, 0) + 7c febe215c thread_entry (253410, 0, 0, 0, 0, 0) + 54 fe9658f0 _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 4 / thread# 4 -------------------- fe965a34 __lwp_park (39f240, fe978b70, 0, 0, fd970600, fe978000) + 14 fe963510 cond_wait (39f240, 39f228, fd17bec0, fded6000, fdec4e9c, 0) + 14 fe96354c pthread_cond_wait (39f240, 39f228, fd970600, 0, 0, 0) + 8 febe20bc gnome_vfs_thread_pool_wait_for_work (39f220, 0, 0, 0, 0, 0) + 7c febe215c thread_entry (39f220, 0, 0, 0, 0, 0) + 54 fe9658f0 _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 5 / thread# 5 -------------------- fe965a34 __lwp_park (39f3d0, fe978b70, 0, 0, fd970800, fe978000) + 14 fe963510 cond_wait (39f3d0, 39f3b8, fd07bec0, fded6000, fdec4e9c, 0) + 14 fe96354c pthread_cond_wait (39f3d0, 39f3b8, fd970800, 0, 0, 0) + 8 febe20bc gnome_vfs_thread_pool_wait_for_work (39f3b0, 0, 0, 0, 0, 0) + 7c febe215c thread_entry (39f3b0, 0, 0, 0, 0, 0) + 54 fe9658f0 _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 6 / thread# 6 -------------------- fe965a34 __lwp_park (3ae9a0, fe978b70, 0, 0, fd970a00, fe978000) + 14 fe963510 cond_wait (3ae9a0, 3ae988, fcf7bec0, fded6000, fdec4e9c, 0) + 14 fe96354c pthread_cond_wait (3ae9a0, 3ae988, fd970a00, 0, 0, 0) + 8 febe20bc gnome_vfs_thread_pool_wait_for_work (3ae980, 0, 0, 0, 0, 0) + 7c febe215c thread_entry (3ae980, 0, 0, 0, 0, 0) + 54 fe9658f0 _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 7 / thread# 7 -------------------- fe965a34 __lwp_park (3aeb30, fe978b70, 0, 0, fd970c00, fe978000) + 14 fe963510 cond_wait (3aeb30, 3aeb18, fce7bec0, fded6000, fdec4e9c, 0) + 14 fe96354c pthread_cond_wait (3aeb30, 3aeb18, fd970c00, 0, 0, 0) + 8 febe20bc gnome_vfs_thread_pool_wait_for_work (3aeb10, 0, 0, 0, 0, 0) + 7c febe215c thread_entry (3aeb10, 0, 0, 0, 0, 0) + 54 fe9658f0 _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 8 / thread# 8 -------------------- fe965a34 __lwp_park (3aecc0, fe978b70, 0, 0, fd970e00, fe978000) + 14 fe963510 cond_wait (3aecc0, 3aeca8, fcd7bec0, fded6000, fdec4e9c, 0) + 14 fe96354c pthread_cond_wait (3aecc0, 3aeca8, fd970e00, 0, 0, 0) + 8 febe20bc gnome_vfs_thread_pool_wait_for_work (3aeca0, 0, 0, 0, 0, 0) + 7c febe215c thread_entry (3aeca0, 0, 0, 0, 0, 0) + 54 fe9658f0 _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 9 / thread# 9 -------------------- fe965a34 __lwp_park (3aee80, fe978b70, 0, 0, fd971000, fe978000) + 14 fe963510 cond_wait (3aee80, 3aee68, fcc7bec0, fded6000, fdec4e9c, 0) + 14 fe96354c pthread_cond_wait (3aee80, 3aee68, fd971000, 0, 0, 0) + 8 febe20bc gnome_vfs_thread_pool_wait_for_work (3aee60, 0, 0, 0, 0, 0) + 7c febe215c thread_entry (3aee60, 0, 0, 0, 0, 0) + 54 fe9658f0 _lwp_start (0, 0, 0, 0, 0, 0)
Created attachment 6906 [details] Metafile which breaks nautilus by bringing up the warning with the NULL str function
Because this was caused by a 1.4 .gnome-desktop file and can't be easily recreated by restoring the file, I'll move the severity to major. But warning messages still shouldn't cause core dumps so here is a suggested fix: I don't yet have a 2.0 cvs build environment but in the XML_GET_VAR_STR macro: http://cvs.gnome.org/bonsai/cvsblame.cgi?file=gnome-xml/error.c&rev=&root=/cvs/gnome #define XML_GET_VAR_STR(msg, str) { \ 22 int size; 23 int chars; 24 char *larger; 25 va_list ap; 26 27 str = (char *) xmlMalloc(150); 28 if (str == NULL) 29 return; How about adding here: if (msg == NULL) return;
This is a classic case where Linux writes out "(null)", but it's not guaranteed to work that way on other platforms. The solution is not to change XML_GET_VAR_STR -- it's not that "msg" is NULL. The problem is that there's a "%s" in the format string, and the passed string is NULL. I'm guessing that "ID" is NULL in the call to the entity loader.
What version of libxml is this? I have the sneaking suspicion this is something that was fixed long ago in the newest libxml.
Our libxml is from the CVS HEAD at 'Thu, 21 Feb 2002 00:08:57 +0000'.
Created attachment 6917 [details] Truss file output of this nautilus crash.
Where is the error ? Are you trying to xmlParseFile(NULL) ??? The stack trace provided is useless because it doesn't describe the parameters and clearly there is a parameter error somewhere but WHERE ? I really can't tell from the information given !!! Daniel
Created attachment 6931 [details] Here is a crash with the source lines, and the contents of msg and str at the time of the crash. Is this a " parsing problem?
This is the result of xmlParseFile(NULL), so it's not a gnome-xml bug.
Fixed in cvs.
Turns out this could be considered either a nautilus or libxml bug. The old libxml1 used to just return NULL if you called xmlParseFile with a NULL filename. The new libxml2 behaves as you discovered here, on Solaris at least. I fixed this by changing nautilus so that it doesn't call xmlParseFile(NULL), but it's also reasonable to change libxml.
Total agreement with Darin on this ! Previous behaviour, NULL was passed as a string format argument orchis:~/XML/python -> python >>> import libxml2 >>> doc = libxml2.parseFile(None) warning: failed to load external entity "(null)" >>> Fixed behaviour, the case of ID == NULL is caught and "NULL" is passed instead: orchis:~/XML/python -> python >>> import libxml2 >>> doc = libxml2.parseFile(None) warning: failed to load external entity "NULL" >>> http://cvs.gnome.org/bonsai/cvsquery.cgi?module=gnome-xml&branch=HEAD&branchtype=match&dir=gnome-xml&file=&filetype=match&who=veillard&whotype=match&sortby=Date&hours=&date=explicit&mindate=03%2F02%2F02+04%3A33&maxdate=03%2F02%2F02+04%3A35&cvsroot=%2Fcvs%2Fgnome thanks for the report, Daniel