From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 Description of problem: I had a filename with bad unicode (from vfat partition). Once a nautilus window on the directory containing this bad filename, then doubleclicking on ANY openoffice document ANYWHERE to open the document caused nautilus to consume all memory and swap and then crash and restart. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Create a filename with bad unicide (nautilus will report (Invalid Unicode) below the filename. My filename had character 0xD0 as one charater 2. Use nautilus to navigate to the directory containing this bad file 3. Double click on any open Office document anywhere (even on the deskto) 4. Watch nautilus die 5. All is well again until that folder is shown by nautilus again Actual Results: Nautilus crashes consuming all memory when opening ocuments Expected Results: Nothing much Additional info:
Can you get us the exact filename? I'm not thinking of a _great_ way to upload the filename; you could make a tar archive of the single file, but that would include the file contents. Maybe just "echo filename > foo.txt" and attach foo.txt would work, maybe instead of typing "filename" type the first letter and push tab so the shell escapes it for you, if it contains chars the shell doesn't like. Thanks!
Created attachment 82344 [details] Tar of file with "bad unicode" name that crashes nautilus eventually
Very strange. I can repeat this every time with the RH8 nautilus, but it crashes in very strange places. It seen to often be in __errno_location in libc (which reads thread local storage). I also saw it once in __pthread_alt_lock. This seems to point to a thread issue of some sort. I also reproduced it by launching gedit on a text file. OOo is not required. Unfortunately this doesn't happen at all in my gnome cvs build, which means either it was fixed, or the different build is hiding the issue.
Tried to valgrind it, but ran out of memory :/
I can't seem to reproduce it on phoebe. Maybe it's fixed.
Marking this fixed, since we haven't seen any dups since then.