update-mime-database segfaults with libxml2-2.6.21 in the function xmlMemFree. The issue appears to be that libxml2 no longer handles NULL values passed to xmlFree() gracefully. A downgrade to libxml2-2.6.20-r2 solved the problem. Program received signal SIGSEGV, Segmentation fault. 0xb7ea0e71 in xmlMemFree__internal_alias (ptr=0x0) at xmlmemory.c:429 429 if (p->mh_tag != MEMTAG) { (gdb) bt #0 0xb7ea0e71 in xmlMemFree__internal_alias (ptr=0x0) at xmlmemory.c:429 #1 0x0804a3e6 in remove_old (type=0x8063c40, new=0x8069c98) at update-mime-database.c:411 #2 0x0804a579 in load_type (type=0x8063c40, node=0x8069a90, error=0xbfecea20) at update-mime-database.c:461 #3 0x0804a7c3 in load_source_file (filename=0x805a630 "/usr/share/mime/packages/freedesktop.org.xml") at update-mime-database.c:533 #4 0x0804aa1c in scan_source_dir (path=0x8050478 "/usr/share/mime/packages") at update-mime-database.c:607 #5 0x0804cdf3 in main (argc=2, argv=0xbfeceb84) at update-mime-database.c:1586
I tried to fix this by putting an if(lang) in front of the xmlfree, but now I'm getting a zillion of these lines: "element comment: error : Reference to default namespace not in scope" interspersed with a couple of these: "element alias: error : Reference to default namespace not in scope"
Created attachment 68146 [details, diff] Patch for shared-mime-info to not call xmlfree with NULL I rebuilt libxml2 without the debug USE flag and now everything is working perfectly. The attached patch is all you need.
That patch is probably good to have too; however update-mime-database _works_ with previous versions of libxml2, where passing NULL is not fatal. I think this crash in update-mime-database is merely a symptom of a libxml2 bug, rather than something that needs fixing in shared-mime-info
Created attachment 68166 [details, diff] Patch for libxml2 to give an error instead of segfaulting when freeing NULL You're right that it is probably a good idea to check for NULL in xmlMemFree, because it helps debugging, but I would not say it's a bug. If it were a bug, you'd also have to check for any other pointer value that's invalid at the time of the call.
I've taken a look at libxml2 and there doesn't seem to be any difference in the source between 2.6.20 and 2.6.21 as far as memory functions is concerned. So it would seem that the reason that we see this crash now is because of the options passed to configure in the 2.6.21 ebuild. Gnome people, please consider the libxml2 patch.
this bug appears to be a duplicate of 105120 (comment #10) *** This bug has been marked as a duplicate of 105120 ***
