GNOME Bugzilla – Bug 374036
[id3v2mux] ID3 Editing is not working correctly, crash injecting frames
Last modified: 2006-11-20 20:16:17 UTC
Please describe the problem: When editing ID3 Tags of MP3s the application shows up an 'Internal GStreamer Problem'. Steps to reproduce: 1. Open Rhythmbox 2. Edit Properties of a MP3 3. Close Dialog 4. Go to another MP3 file --> error occurs Actual results: The tag seems to be edited, even though the error dialog appears. the next time rhythmbox is started the tags are "reset". Expected results: The ID3 Tags are changed correctly. Does this happen every time? Yes Other information:
+ Trace 85564
Thread 3 (Thread -1299035232 (LWP 3917))
Thread 1 (Thread -1228818768 (LWP 3718))
Created attachment 76407 [details] Stack Trace This is a stack trace using BugBuddy. I am using Ubuntu 6.10
There's a chance that this is the same as bug #359083 (similar stacktrace and symptoms). Can you try CVS version of rhythmbox to see if the issue persists?
The crash is actually inside taglib, but the problem may be in id3v2mux, so I'm moving the bug to gst-plugins-good. Reporter almost certainly has -good 0.10.4. There haven't been any relevant-looking fixes to id3v2mux since then. Note: the stack trace in comment 0 doesn't mean anything as it's from the main rhythmbox process. The one in comment 1 is from the rhythmbox metadata helper process, which is what's actually crashing here. The pipeline we're using here will look something like gnomevfssrc ! id3demux ! id3v2mux ! gnomevfssink Markus, if you could get another stack trace with debug symbols for gst-plugins-good installed (see http://live.gnome.org/GettingTraces for more information), that would be useful.
taglib debugging symbols might be useful as well. If you can reproduce that crash every time with a specific file, it would be great if you could make it available in some way.
Created attachment 76587 [details] Stack Trace with DBG installed Attached please find the Stacktrace, as well as the ID3 Tag. I can put this file also on a Web-Site if needed: id3v1 tag info for G. ABBA - Gold Greatest Hits - 08 - The Winner Takes It All.mp3: Title : The Winner Takes It All Artist: ABBA Album : ABBA Gold - Greatest Hits Year: 2000, Genre: Rock (17) Comment: Track: 8 id3v2 tag info for G. ABBA - Gold Greatest Hits - 08 - The Winner Takes It All.mp3: TT2 (Title/songname/content description): The Winner Takes It All TP1 (Lead performer(s)/Soloist(s)): ABBA TAL (Album/Movie/Show title): Mix TCO (Content type): 70s (255) COM (Comments): (iTunNORM)[eng]: 00000524 000005FC 000020F2 000031FD 0001D4EE 00044605 00004EDC 000057CF 00044605 00044605
Probably I should have stated, that I am using an NFS-Share for the music library.
Thanks for the new stack trace. Looks like a rhythmbox problem to me:
+ Trace 86461
Thread 1 (Thread -1495357216 (LWP 26419))
Don't know whether it's the same as bug #359083, but looks at least similar.
That is another instance of bug 359083. Markus, we need a stack trace from when tag editing results in an "internal GStreamer problem" error message (like the one in comment 1), rather than the whole application crashing.
The thing is, that the error appears, and I don't get a stacktrace like the one before anymore :-( I am just getting an error message, but nothing more. When I try to edit the same file another time, I am getting the attached stacktrace. I do not seem to be able to get the stacktrace during the time, when the error occurs. Furthermore, Rhythmbox seems to create "backups" of the MP3 files, in the directory I see now two different files, one with *.mp3 and the other one with some strage extension like *.mp3760E93.
Created attachment 76623 [details] Stacktrace (with DBG)
Could you run rhythmbox from a command line like this: $ export GST_DEBUG_NO_COLOR=1 $ GST_DEBUG=*:5 rhythmbox 2>dbg.log ... do whatever you do to reproduce the error, then close rhythmbox ... $ gzip dbg.log and attach the dbg.log.gz file?
Created attachment 76653 [details] Debug Log I tried to rename an MP3 from A Ha to AHA. ID3V2 -l: id3v1 tag info for 01 - 1985 - A Ha - Take On Me.mp3: Title : Take On Me Artist: AHA Album : Sounds of the Eighties Year: 1985, Genre: Other (12) Comment: In Rhythmbox this file is shown with the artist "A Ha".
I forgot to ask: what is the exact error message that you get in the error dialog?
Quite hard, because I am using a german version: Fehler beim Speichern der Titelinformationen Internes GStreamer-Problem; füllen Sie einen Fehlerbericht aus translated something like: Error at saving the title information internal GStreamer-Problem: please fill out an error-report. Don't know, if this is correct, but it is pretty much the translation.
That's the message rhythmbox uses when the metadata helper process crashes or doesn't respond within some arbitrary time limit (I think 15 seconds).
What does this mean? GStreamer crashes, but why?
According to the log there aren't any GStreamer errors, and I couldn't find anything else suspicious either in the log. And as far as I can see, we don't have a stack trace indicating a crash in GStreamer either, do we? In short: I have absolutely no idea what's going on here.
The first one show a crash in gstreamer: #0 0xb5223a01 in TagLib::ID3v2::TextIdentificationFrame::parseFields () from /usr/lib/libtag.so.1 #0 0xb5223a01 in TagLib::ID3v2::TextIdentificationFrame::parseFields () from /usr/lib/libtag.so.1 No symbol table info available. #1 0xb52242de in TagLib::ID3v2::TextIdentificationFrame::TextIdentificationFrame () from /usr/lib/libtag.so.1 No symbol table info available. #2 0xb521c719 in TagLib::ID3v2::FrameFactory::createFrame () from /usr/lib/libtag.so.1 No symbol table info available. #3 0xb525a72e in gst_id3v2_mux_plugin_init () (or rather in taglib after going through gstreamer), but the ones with debug symbols do not :-/
You can find the file on: http://javafreedom.org/private/01%20-%201985%20-%20A%20Ha%20-%20Take%20On%20Me.mp3 Hope this helps.
Thanks, can reproduce this on dapper/x86 with gstreamer from CVS.
Looks to me like the TENC frame in the ID3v2 tag is broken and taglib crashes parsing that in this case because it doesn't check whether the data it wants to read is actually available (in a normal tag reading situation it would just read into the data of the following tags in most cases, so it's less likely to cause any problems under other circumstances). 00000000 49 44 33 04 00 00 00 00 02 0e 54 45 4e 43 00 00 |ID3.......TENC..| 00000010 00 01 20 01 00 57 58 58 58 00 00 00 02 00 01 00 |.. ..WXXX.......| 00000020 00 54 43 4f 50 00 00 00 01 00 01 00 54 4f 50 45 |.TCOP.......TOPE| 00000030 00 00 00 01 00 01 00 43 4f 4d 4d 00 00 00 68 00 |.......COMM...h.| The TENC frame is: 54 45 4e 43 TENC frame marker 00 00 00 01 Size of frame without the 10 bytes frame header 20 01 Frame flags: - File alter preservation: discard frame if mp3 is altered - Data length indicator: a 4-byte data length indicator has been added to this frame 00 One fourth of the expected 4-byte data length indicator Bytes missing are at least: - 3 bytes: rest of 4-byte data length indicator - 1 byte: string encoding - 1 byte: terminator for string #1
Forwarded to taglib bug tracker with possible patch: http://bugs.kde.org/show_bug.cgi?id=137635