GNOME Bugzilla – Bug 122416
[lame] Seg Fault when writing ID3 to MP3
Last modified: 2005-01-29 11:47:48 UTC
When ripping "Heathen" by David Bowie with s-j 0.5.2, I'd left s-j on a different workspace, and it had probably come to the end of ripping track one (judging by the backtrace) and was writing the ID3 tag, when it seg faulted. This has happened each time I've tried to rip this CD - I've not tried any others yet... Backtrace was generated from '/opt/gnome2/bin/sound-juicer' [New Thread 16384 (LWP 18460)] 0x40926cf7 in waitpid () from /lib/libpthread.so.0
+ Trace 40214
Thread 1 (Thread 16384 (LWP 18460))
Created attachment 19975 [details] [review] avoid crash when the prop isn't found
Hi. We're suspecting this bug will also be in vorbisenc. Can you rerip the track, this time ripping to ogg, and file a new backtrace if it breaks ? We'll work on this bug and put up a patch.
Seg fault still happens with this patch, here's the trace: Backtrace was generated from '/opt/gnome2/bin/sound-juicer' [New Thread 16384 (LWP 2437)] 0x40926cf7 in waitpid () from /lib/libpthread.so.0
+ Trace 40218
Thread 1 (Thread 16384 (LWP 2437))
D'oh! Didn't see the rerip request in time... Ok, re-ripping to OGG... Doesn't crash.
A bit more information, I just noticed that it when it crashed ripping to MP3, it had started the second track - created the file, but it's of zero length. Hope that helps.
Can you attach a debugger and do "frame 5" and then "print *caps" on the crashing thread? caps = 0xfffffe00 does not look good, I'm suspecting memory corruption elsewhere.
Program received signal SIGSEGV, Segmentation fault.
+ Trace 40219
Thread 16384 (LWP 3193)
No symbol "caps" in current context.
Not that one. ;). [New Thread 16384 (LWP 2437)] 0x40926cf7 in waitpid () from /lib/libpthread.so.0
+ Trace 40222
There, in this trace, I need the value of the symbol caps plus its contents in #5.
Sorry, I'm not a gdb guru - a quick guide to how to isolate that would be appreciated :)
*** Bug 122432 has been marked as a duplicate of this bug. ***
*** Bug 122434 has been marked as a duplicate of this bug. ***
First, start gd and attach to the crashing process. Then, use "up" and "down" to find the appropriate frame, then use "print *caps" to print the properties of the values in caps.
I've having a different backtrace when ripping to mp3 with sound-juicer : Program received signal SIGSEGV, Segmentation fault. 0x410b8567 in id3tag_set_title () from /home/gnome/prefix//lib/libmp3lame.so.0 (gdb) bt
+ Trace 40397
$1 = {name = 0x81f47f8 "intersect", id = 2, flags = 1, refcount = 2, properties = 0x80e6f54, next = 0x0}
*** Bug 123388 has been marked as a duplicate of this bug. ***
The problem seems to be with using the same pipeline for 2 different tracks, probably memory corruption. Is there a way to disable the MMX/SSE/whatever extensions in GST to debug it using valgrind or similar?
--disable-cpu-opt, but that's only available in 0.6.x CVS (and HEAD CVS), not in 0.6.3.
*** Bug 123689 has been marked as a duplicate of this bug. ***
Can this bug be reproduced in 0.8.0?
This code no longer exists. I've had a small look back at the 0.6 code, and from what I can see, memory for metadata was shared between app and plugin. This means that if SJ would rip a next track after having free'ed its previous metadata, the data would still be in the plugin and it'd access invalid memory. This is no longer the case in 0.8, we now use proper memory referencing to prevent this. Therefore, this probably doesn't occur in 0.8 anymore. I'll close it as INVALID since I don't know what else to do with it.