Red Hat Bugzilla – Bug 76774
Bad unicode breaks nautilus open application
Last modified: 2015-01-07 19:01:21 EST
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):
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
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.
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.