GNOME Bugzilla – Bug 549326
Crash on continuous/repeated seeks on mp3
Last modified: 2008-09-01 09:13:16 UTC
Steps to reproduce: 1. Play stackoverflow-podcast-001.mp3 (http://blog.stackoverflow.com/audio/stackoverflow-podcast-001.mp3, sha1 4cbe6242b721b3b54676808b8848f583c4446155) 2. Grab the slider-seeker thing (the one you use to fast forward and rewind) and slide it back and forth until totem crashes. If you get an assertion failure on object != NULL, goto 2. It'll go away Stack trace: (gdb) bt
+ Trace 205649
Other information: The output from totem when I ran it without debug symbols was as follows: GLib-ERROR **: /build/buildd/glib2.0-2.16.4/glib/gmem.c:136: failed to allocate 4196449684 bytes aborting... I didn't capture the output of the with-debug-symbols run, but I assume it'd be s/4196449684/4039640116/. Also, unsurprisingly, 255327180 + 4039640116 is 2**32 (note the size parameter in the stack trace). If you send me two gigs of ram, I'll happily tell you what happens on a four gig machine ;)
What versions of the various modules (core/base/good/ugly) are you using? I'm sure I've seen this before and it's fixed, but I can't find the corresponding bug right now.
I *think* this was bug #533581 and should be fixed in gst-plugins-ugly 0.10.8 (you can check your version of the mad mp3 decoder plugin with 'gst-inspect-0.10 mad | grep Version' in a terminal)
Yeah, that bug (#533581) sounds exactly like it. Inspecting mad says the version is 0.10.7. Trying things out on my debian box (which has gstreamer0.10-plugins-ugly at version 0.10.8-1), I can't reproduce the bug, so I think this is it. Public note to self: when stuff fails on ubuntu, go test on your debian box *before* filing bug reports; debian has newer stuff due to its testing branch. Sorry to have wasted your time :)
No worries, thanks for confirming it's the same issue. Please re-open if it still happens with a newer ubuntu. *** This bug has been marked as a duplicate of 533581 ***