GNOME Bugzilla – Bug 306143
Probably corrupted data type make nautilus freeze or crash
Last modified: 2005-12-18 17:19:21 UTC
Steps to reproduce: I deleted my .local file but problem remain. Stack trace: Other information:
Hi there. I can't use that bug report for anything without more information. Please could you specify what you did so that nautilus crashed and also submit a stack trace? See http://live.gnome.org/GettingTraces for more information. Thanks!
Here are more informations : garnome 2.10.1 is installed on a NFS share in /opt/STools/gnome-2.10 all users have a fedora core 3 slightly modify to make gdm run /opt/STools/gnome-2.10/bin/gnome-session (without dbus-launch). All users have the nautilus freezing problem. It sometimes crahes instead of freezing but no core available since gnome-session say : "Multiple segmentation faults occurred; can't display error dialog" Anyway , I had some backtrace thanks to gcore. I always have this sort of messages just before it hangs : *** glibc detected *** corrupted double-linked list: 0xb6321f98 *** OR *** glibc detected *** double free or corruption (fasttop): 0xb63148e0 *** OR *** glibc detected *** free(): invalid pointer: 0xb630ad60 *** Next I'll post some backtrace
+ Trace 60426
Using host libthread_db library "/lib/tls/libthread_db.so.1". Core was generated by `/opt/STools/gnome-2.10/bin/nautilus'.
+ Trace 60428
Thread 12 (process 5928)
*** glibc detected *** corrupted double-linked list: 0x00242838 *** BACKTRACE : Using host libthread_db library "/lib/tls/libthread_db.so.1". Core was generated by `/opt/STools/gnome-2.10/bin/nautilus'.
+ Trace 60431
Thread 12 (process 6717)
Finishing strace (just before hang) read(3, "\4\3j\r@\254\263\0@\0\0\0v\2`\2\0\0\0\0O\3\330\2$\0029"..., 64) = 64 gettimeofday({1117641594, 66938}, NULL) = 0 futex(0x81962ac, FUTEX_WAKE, 1) = 1 ) = 0 stat64("/opt/STools/gnome-2.10/share/mime-info/palm.keys", futex(0x8196288, FUTEX_WAKE, 1) = 0 lstat64("/opt/STools/gnome-2.10/share/mime-info/palm.keys", {st_mode=S_IFREG|0644, st_size=388, ...}) = 0 select(17, [16], NULL, NULL, {0, 0}{st_mode=S_IFREG|0644, st_size=388, ...}) = 0) = 0 (Timeout) open("/opt/STools/gnome-2.10/share/mime-info/palm.keys", O_RDONLY|O_LARGEFILEwrite(16, ":\0\1\0\6\1\1\0000\0/opt/STools/gnome-2.10"..., 58) = 58 gettimeofday({1117641594, 68142}, NULL) = 0 gettimeofday({1117641594, 68209}, NULL) = 0 lstat64("/opt/STools/gnome-2.10/share", ) = 26 {st_mode=S_IFDIR|S_ISUID|S_ISGID|0755, st_size=3072, ...}) = 0 gettimeofday(stat64("/home/olelain", {1117641594, 68801}, NULL) = 0 {st_mode=S_IFDIR|0755, st_size=7168, ...}) = 0 stat64("/home/olelain/.local/share//mime/globs", gettimeofday({1117641594, 68996}, NULL) = 0 stat64("/home/olelain/.local/share//mime/globs", {st_mode=S_IFREG|0664, st_size=92, ...}) = 0 stat64("/home/olelain/.local/share//mime/magic", {st_mode=S_IFREG|0664, st_size=92, ...}) = 0 {st_mode=S_IFREG|0664, st_size=12, ...}) = 0 futex(0x242800, FUTEX_WAKE, 1futex(0x242800, FUTEX_WAIT, 2, NULL) = 0 ) = -1 EAGAIN (Resource temporarily unavailable) futex(0x242800, FUTEX_WAIT, 2, NULLopen("/dev/tty", O_RDWR|O_NONBLOCK|O_NOCTTY) = -1 ENXIO (No such device or address) writev(2, [{"*** glibc detected *** ", 23}, {"double free or corruption (out)", 31}, {": 0x", 4}, {"0831d848", 8}, {" ***\n", 5}], 5) = 71 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 tgkill(7598, 7609, SIGABRT) = 0 --- SIGABRT (Aborted) @ 0 (0) --- write(3, "\22\0\7\0@\2`\2\1\1\0\0\6\0\0\0 \3\5\0\1\0\0\0@\254\263"..., 36) = 36 write(3, " \0\2\0\0\0\0\0", 8) = 8 write(3, "+\0\1\0", 4) = 4 read(3, "\34\310k\r@\2`\2\1\1\0\0E\254\263\0\0\2`\2\1\0\0\0H\310"..., 32) = 32 read(3, 0xb64cd834, 32) = -1 EAGAIN (Resource temporarily unavailable) select(4, [3], NULL, NULL, NULL) = 1 (in [3]) read(3, "\1\2n\r\0\0\0\0A\2`\2\0\0\0\0\0\0\0\0\34\0\0\0\310\f\265"..., 32) = 32 futex(0x242800, FUTEX_WAIT, 2, NULL[olelain@trevezel ~]$
palm.keys is seen as Mime-type=octet-stream All other keys files are seen as text/plain
Just append : a crash with a core generated *** glibc detected *** realloc(): invalid next size: 0xb632f2b0 *** *** loading the extensions datasource seahorse nautilus module initialized BACKTRACE : Using host libthread_db library "/lib/tls/libthread_db.so.1". Core was generated by `/opt/STools/gnome-2.10/bin/nautilus'.
+ Trace 60457
Thread 12 (process 15345)
*** Bug 167284 has been marked as a duplicate of this bug. ***
*** Bug 306866 has been marked as a duplicate of this bug. ***
I think it's relative to the files in the PREFIX/share/mime Some have UTF-8 charset (xml files) and some ascii 7 bits(those generated by update-desktop-databses) There must be a problem in the way memory is allocated and then dealocated in xdgmimeparent.c when it "composes" the mime-type , probably due to the different size of both encodings : void _xdg_mime_parent_read_from_file (XdgParentList *list, const char *file_name) { FILE *file; char line[255]; int i, alloc; XdgMimeParents *entry; file = fopen (file_name, "r"); if (file == NULL) return; /* FIXME: Not UTF-8 safe. Doesn't work if lines are greater than 255 chars. * Blah */ alloc = list->n_mimes + 16; list->parents = realloc (list->parents, alloc * sizeof (XdgMimeParents)); while (fgets (line, 255, file) != NULL) ...
Maybe it can be easily reproduced with the mime test programs from gnome-vfs and "playing" with enca for changing the charset of mime files. http://trific.ath.cx/software/enca/ I'll try as soon as I have time to. Just a clue , I'm just an IT, not a developper :-)
The only file parsed by xdg_mime_parent_read_from_file is share/mime/subclasses, this file should be pure ascii, so I don't think the problems will arise from encoding confusion. There's https://bugs.freedesktop.org/show_bug.cgi?id=3506 which contains a fix for a bad memory allocation, but I'd be a bit surprised if this was related. But it still can, who knows :)
*** Bug 304235 has been marked as a duplicate of this bug. ***
*** Bug 306885 has been marked as a duplicate of this bug. ***
Another one , even if I doubt it will help to faire avancer le schmilblick.. BACKTRACE : Using host libthread_db library "/lib/tls/libthread_db.so.1". Core was generated by `/opt/STools/gnome-2.10/bin/nautilus'.
+ Trace 60796
Thread 12 (process 4180)
Maybe the patch from https://bugs.freedesktop.org/show_bug.cgi?id=3506 would help, but I'm mainly shooting in the dark :-/
can you try the pointed patch?
Yes that's very strange. I can't reproduce it since gnome-vfs monitors new files (really new of moved). After a dozen of crashes, it is quiet for a moment (never more than one hour). Anyway , won't it be possible to return a failure status code from the gnome-vfs mime api, so that at least it doesn't make nautilus freeze. (having an "unknown" mime type,or even a wrong one would be painless) I could try the patch but I'm not sure about the procedure : (and I want to avoid a Nightmare Monday since dozen of users utilize the same libgnomevfs.so :-) ) just replacing the xdgmime.c attached in https://bugs.freedesktop.org/show_bug.cgi?id=3506 and recompiling gnome-vfs is enough ?
Yes, please try the patch from the bug mentioned in comment #17. This bug could subtly lead to memory corruption in things surrounding xdgmime.
I just checked gnome-vfs from the 2.10 branch on CVS, and it has a different (older?) copy of xdgmime than, say, GTK+. So this patch won't work out of the box for it.
I just applied the patch to gnome-vfs HEAD.
I just patch gtk+ ? I realize It's a bit out of purpose there since I should have patched gnome-vfs. Anyway it wasn't unusefull since it correct one big bug I had (still out of purpose,anyway): GtkFileChooser doesn't crash anymore with Sunbird and DeerPark ...
Yeah, the 2.10 branch uses an xdgmime version without the binary cache, the cache was added not too long before the 2.10 release, so it sounded a bit risky to add it. Did you check the only difference between HEAD and xdgmime CVS was your patch? I make one way syncs between freedesktop xdgmime code and gnome-vfs, but I try to avoid applying random patches to gnome-vfs xdgmime code.
Yes,indeed !! I don't want to take the risk to use the cvs version. Is there a hope to have the patch applied to the "original" 2.10.1 version or do I definitively have to wait for 2.10.2 ? As for kernel, It would be great to have a 2-10-1-bf (bug fix) branch !! :-)
How different would a 2.10.1.bf would be from 2.10.2 ? ;)
I don't want to create the same flame as the 2.6.11.1..etc one !! :-) But as your mentioned it right in #24, "cache api" visibly has been added to the 2.10 branch : so you can't just patch this bug without using this new "api". But I don't care about the bf name : just call it -oll ( so that I know it's for me ;) ) Resuming, I don't know which files of the original 2.10.1 I have to patch to solve the https://bugs.freedesktop.org/show_bug.cgi?id=3506
The cache stuff has been added to the 2.11 branch, and I'd rather avoid adding it to the 2.10 branch. So 2.10 is an actual stable branch with no api change, only bug fixes, while the 2.11 branch is where the development happens.
Oups, sorry : I was sure I choosed 2-10 tag in viewcvs : I just recheck it and it wasn't obviously the case : sorry for my confusion. But precisely, will the patch be available for the 2.10 branch or is there finally no link, since 2.10 doesn't use cache ? Something else : this ones seem to be the related: http://bugzilla.gnome.org/show_bug.cgi?id=306259 http://bugzilla.gnome.org/show_bug.cgi?id=306251
I know there are quite a bunch of crashes in xdgmime these days, but without a way to reproduce them, I can't really fix it since I couldn't find anything obvious :-/
The patch I pointed out is useless in 2.10, so the cause of the crash must be something else :(
I almost always have this crash with gnome-search-tools : BACKTRACE : Using host libthread_db library "/lib/tls/libthread_db.so.1". Core was generated by `/opt/STools/gnome-2.10/bin/gnome-search-tool'.
+ Trace 61160
Thread 2 (process 13802)
can you install a debug version of gnomevfs?
Unfortunatly, I think it will be hard : I presume I have to recompile/reinstall with -g . But If i do that , all my stations will crash since libgnomevfs.so will be replaced. Anyway, is there a solution to do it "a posteriori" ? I mean without to have to rehave a new libgnomevfs.so ?
On linux at least, this shouldn't matter (ie this shouldn't crash anything).
Here it is : it seems indeed more usefull. BACKTRACE : Using host libthread_db library "/lib/tls/libthread_db.so.1". Core was generated by `/opt/STools/gnome-2.10/bin/gnome-search-tool'.
+ Trace 61168
Thread 2 (process 21368)
This one is a gcore from a freeze : (i was right clicking on a file) *** glibc detected *** realloc(): invalid next size: 0x085eef20 *** BACKTRACE : Using host libthread_db library "/lib/tls/libthread_db.so.1". Core was generated by `/opt/STools/gnome-2.10/bin/nautilus'.
+ Trace 61171
Thread 11 (process 21285)
Did you include any optimization flag (-O2 for example) when you recompile with -g ? If so, could you get a backtrace with a lib compiled with -g -ggdb and without any -O option ? Thanks
yes indeed : [olelain@trevezel ~]$ echo $CFLAGS -march=pentium4 -mtune=pentium4 -msse2 -mfpmath=sse -O2 -g CFLAGS="-g -ggdb" ? or CFLAGS="-g -ggdb -march=pentium4 -mtune=pentium4 -msse2 -mfpmath=sse" ??
CFLAGS="-g -ggdb"
Here it is : *** glibc detected *** double free or corruption (!prev): 0x0813a190 *** BACKTRACE : Using host libthread_db library "/lib/tls/libthread_db.so.1". Core was generated by `/opt/STools/gnome-2.10/bin/gnome-search-tool'.
+ Trace 61174
Thread 2 (process 21421)
Now a freeze (gcored) *** glibc detected *** realloc(): invalid next size: 0xb6420a10 *** BACKTRACE : Using host libthread_db library "/lib/tls/libthread_db.so.1". Core was generated by `/opt/STools/gnome-2.10/bin/nautilus'.
+ Trace 61178
Thread 7 (process 21315)
*** Bug 308129 has been marked as a duplicate of this bug. ***
Is this the answer : ?? http://bugzilla.gnome.org/show_bug.cgi?id=170947
Looks like a strong candidate, since I was thinking about threading issue after looking at your backtraces. Could you test the patch?
*** Bug 308392 has been marked as a duplicate of this bug. ***
Unfortunatly , I applied the patch and got another core. But I just did a patch, then make then make install. Maybe I have to do a make clean before (or is it definitively useless ?) *** loading the extensions datasource BACKTRACE : Using host libthread_db library "/lib/tls/libthread_db.so.1". Core was generated by `/opt/STools/gnome-2.10/bin/gnome-search-tool'.
+ Trace 61329
Thread 2 (process 15890)
Another trace with : * max debug in glib and gnome-vfs. * patch from http://bugzilla.gnome.org/show_bug.cgi?id=170947 * some printf added by Christophe. Anyway, it seems I have less crashes with the 170947 patch. (none from nautilus till there) olelain : gnome-search-tool has crashed Core file is /tmp/crash.gnome.6067 20 LAST LINES IN GNOME LOG xdg_mime_init2: 0x8267c28 xdg_mime_init: 0 xdg_mime_init2: 0x8267c28 xdg_mime_init: 0 xdg_mime_init2: 0x8267c28 xdg_mime_get_mime_type_from_file_name: 0x8267c28 xdg_mime_init: 0 xdg_mime_init2: 0x8267c28 xdg_mime_init: 0 xdg_mime_init2: 0x8267c28 xdg_mime_init: 0 xdg_mime_init2: 0x8267c28 xdg_mime_get_mime_type_from_file_name: 0x8267c28 xdg_mime_init: 0 xdg_mime_init2: 0x8267c28 xdg_mime_init: 0 xdg_mime_init2: 0x8267c28 xdg_mime_init: 0 xdg_mime_init2: 0x8267c28 xdg_mime_in BACKTRACE : Using host libthread_db library "/lib/tls/libthread_db.so.1". Core was generated by `/opt/STools/gnome-2.10/bin/gnome-search-tool'.
+ Trace 61344
Thread 2 (process 6069)
The debugging info is more or less useless without showing the patch you applied... The relevant line from the backtrace which explains the crash is
+ Trace 61348
The added printf seems to indicate that at some point in time, we leave xdg_mime_init with a NULL global_hash, dunno yet how that can happen. xdg_mime_shutdown doesn't seem to be called, and even if it was, need_reread would be set to true.
Created attachment 48103 [details] [review] christophe's patch
That's gnome-vfs 2.10.1 plus the 2 attached patches + this printf added : Tu peux ajouter un printf dans xdgmime.c:xdg_mime_init : /* Called in every public function. It reloads the hash function if need be. */ static void xdg_mime_init (void) { if (xdg_check_time_and_dirs ()) { printf ("Shutting down\n"); xdg_mime_shutdown (); }
Created attachment 48104 [details] [review] 170947's patch
I applied the 48104 attachment at the beginning of the week and users complain no more about Nautilus. So I really think it solves at least 95% of the problem. Just gnome-search-tool which goes on crashing some rare times.
*** Bug 308780 has been marked as a duplicate of this bug. ***
hmm. Finally nautilus goes on crashing some times , even with the mime patch. ..even if it's far less often.
*** Bug 305541 has been marked as a duplicate of this bug. ***
do you have the same backtrace with the patch? Maybe this issue is fixed and you have an another bug. When do you get the issue with the patch?
Some users go on having the bug (as I told before , far less often). Unfortunatly, I didn't have it myself since weeks so no other useful bt to give.
*** Bug 312466 has been marked as a duplicate of this bug. ***
Hmm, finally, I'm pretty sure that it always and only happens after an upgrade-mime-database.
Latest patch from Alex Larsson in cvs 2.10 branch ( again many thanks to him to have taken time to commit it in 2.10 branch while I guess there's a lot of things to do with 2.12). For me and my 50 users, this bug belongs to past. I prefer let Christophe (or other maintainers) close it regarding my poor C level. Thanks to all again.
Marking as fixed then.
*** Bug 323973 has been marked as a duplicate of this bug. ***