GNOME Bugzilla – Bug 108482
open file properties in long-named directory , crash.
Last modified: 2004-12-22 21:47:04 UTC
Subject: open mp3 file properties with utf8 id3 tags, crash. Package: nautilus Severity: normal Version: GNOME2.2.1 2.2.2 os_details: Gnome.Org Synopsis: open mp3 file properties with utf8 id3 tags, crash. Bugzilla-Product: nautilus Bugzilla-Component: nautilus-media BugBuddy-GnomeVersion: 2.0 (2.2.0.1) Description: Description of Problem: open mp3 file properties with utf8 id3 tags, crash. Steps to reproduce the problem: 1. select mp3 file with utf8 encoded id3 tag 2. click right mouse button 3. select properties Actual Results: nautilus crashed. Expected Results: open file properties How often does this happen? always. mp3 file has id3 v1and v2 tags. Additional Information: Debugging Information: Backtrace was generated from '/usr/bin/nautilus' (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...[New Thread 16384 (LWP 31032)] [New Thread 32769 (LWP 31034)] [New Thread 16386 (LWP 31035)] [New Thread 32771 (LWP 31036)] [New Thread 49156 (LWP 31037)] [New Thread 65541 (LWP 31038)] [New Thread 81926 (LWP 31039)] [New Thread 98311 (LWP 31040)] [New Thread 114696 (LWP 31041)] [New Thread 131081 (LWP 31042)] [New Thread 147466 (LWP 31043)] [New Thread 163851 (LWP 31044)] (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... 0x409a120a in waitpid () from /lib/libpthread.so.0
+ Trace 34943
Thread 1 (Thread 16384 (LWP 31032))
*** Bug 106806 has been marked as a duplicate of this bug. ***
can someone make a small test file with utf8 tags available that crashes so I can work on this ?
uh.. sorry. nautilus crash is cause directory name, not id3 tag. i attach a tarball with that directory and mp3 file with utf8 id3 tag. (directory name is utf8-encoding)
Created attachment 15957 [details] test tarball included long-named utf8 encoding directory and sample mp3
*** Bug 113434 has been marked as a duplicate of this bug. ***
Bug 113434, the latest duplicate, contains a stack trace with debugging symbols in an attachment. Note that the subject for bug 113434 is "Nautilus crashes after cut/copy'n'paste/delete operations". Bug 113434 may contain more useful information as well--the two people experiencing it have added a couple comments now. Since this is a crasher bug, I'm marking priority->high and severity->critical. Due to the stack trace with debugging symbols in bug 113434, I'm addin the STACKTRACE keyword. I'm also adding the bugsquad keyword.
This looks like a duplicate of bug 95786, which was marked as fixed by Alex L. The only difference is that bug 95786 has the function pango_layout_iter_next_char near the beginning of the stack trace whereas this stack trace has the function pango_layout_iter_get_char_extents. Are they duplicates--if so, should 95786 be reopened?
Judging by the date on comment in bug 95786, the patch would have been committed to cvs in January (or earlier) and thus eel 2.2.3 should include it. I'm running nautilus 2.2.3 (linked to eel 2.2.3), and it exhibits this bug which means it's a different bug ... (or the fix did not cover all cases)
*** Bug 123310 has been marked as a duplicate of this bug. ***
Setting Version->2.4.x, adding GNOMEVER2.4, GNOMEVER2.5 keywords.
This is probably a dup of 120891; I posted there a little program that exposes a segfault in pango_layout_iter_get_char_extents
I can't reproduce the crash with the attached tarball on HEAD. Since there are no recent duplicates, I'm going with the theory that this is a dup of bug 120891. *** This bug has been marked as a duplicate of 120891 ***
*** Bug 146090 has been marked as a duplicate of this bug. ***