GNOME Bugzilla – Bug 579632
Totem crashes with failed memory allocation
Last modified: 2009-10-28 14:12:59 UTC
Steps to reproduce: 1. Download <http://www.archive.org/download/CR_2006_01/CR-2006-01.mov> (147MB) 2. Play it 3. Wait about 15s Stack trace:
+ Trace 214640
Other information: There is also some crackling on audio output, but that is for another bug. Debug output: ** (totem:32710): DEBUG: Init of Python module ** (totem:32710): DEBUG: Registering Python plugin instance: BBCViewer+TotemPythonPlugin ** (totem:32710): DEBUG: Creating object of type BBCViewer+TotemPythonPlugin ** (totem:32710): DEBUG: Creating Python plugin instance ** (totem:32710): DEBUG: Init of Python module ** (totem:32710): DEBUG: Registering Python plugin instance: YouTube+TotemPythonPlugin ** (totem:32710): DEBUG: Creating object of type YouTube+TotemPythonPlugin ** (totem:32710): DEBUG: Creating Python plugin instance GLib-ERROR **: /build/buildd/glib2.0-2.18.2/glib/gmem.c:136: failed to allocate 192000 bytes aborting... zsh: abort totem CR-2006-12.mov
Created attachment 132972 [details] Result of GStreamer debug Ran the command: $ GST_DEBUG_NO_COLOR=1 GST_DEBUG=*:2 totem CR-2006-12.mov --gst-debug-level=5 2> /tmp/totemout.log
Created attachment 132973 [details] Output of gst-launch-0.10 Ran the command: $ gst-launch-0.10 playbin uri=file:///.../CR-2006-01.mov 1>/tmp/gstout.log 2>&1
I suspect you were out of memory. GLib-based applications abort if memory allocation fails; it's not a Totem bug.
No, I am not. I have 2GB RAM plus 5.7GB swap, which is less than half used. My system has plenty of memory. It is, however, a 32-bit system. At the time of the crash, totem is using: * 100.3MB memory * 3.0GB virtual memory * 124.4MB resident * 100.1MB writable * 24.4MB shared (thank you, system monitor) I believe that totem (specifically, gstreamer) exhausted its space. I don't understand why it would need >3000MB of memory for a file which is 140MB.
That's interesting. This is more a GStreamer bug rather than a Totem bug, since you can reproduce it with gst-launch, though it may well get passed further down the stack by the GStreamer people.
What's the output: $ gst-inspect-0.10 fakesink | grep Version $ gst-inspect-0.10 playbin | grep Version $ gst-inspect-0.10 gconfaudiosink | grep Version $ gst-inspect-0.10 ffmpeg | grep Version $ gst-inspect-0.10 qtdemux | grep Version ? I can't reproduce this. Memory usage seems steady for me with the latest releases and git.
Closing as no additional information was provided and nobody can reproduce it.
Sorry, missed the email the first time. This bug seems to no longer trigger. (Although this file is problematic for other reasons; ever player other than Quicktime seems to get confused.)
(In reply to comment #8) > Sorry, missed the email the first time. > > This bug seems to no longer trigger. (Although this file is problematic for > other reasons; ever player other than Quicktime seems to get confused.) If you could attach the file to this bug report (or the first 1000KiB of it, if that reproduces the problem), then perhaps the other problems with it could be fixed.
(In reply to comment #9) > (In reply to comment #8) > > Sorry, missed the email the first time. > > > > This bug seems to no longer trigger. (Although this file is problematic for > > other reasons; ever player other than Quicktime seems to get confused.) > > If you could attach the file to this bug report (or the first 1000KiB of it, if > that reproduces the problem), then perhaps the other problems with it could be > fixed. Scrap that; I just noticed it's the first link in your first comment.
(In reply to comment #8) > Sorry, missed the email the first time. > > This bug seems to no longer trigger. (Although this file is problematic for > other reasons; ever player other than Quicktime seems to get confused.) I can't see any problems when playing the file. Could you produce a GStreamer debug log of the new problem occurring please?
The basic problem is that the file is structured very strangely. Totem (and VLC for a while) have issues playing the different video segments in the correct order. This has been true for as long as I've tried to play this file. When totem plays it, it initially shows segment 2 (talking head) instead of the introductory montage. Currently, VLC seems to play it in the correct order.
The file contains 3 tracks, 1 audio (with 12 edit list entries) and 2 videos (both h263 and one having 3 and the other 5 edit list entries). Don't know how the play order is defined for file like these. Anyone? Shouldn't we change the bug title or open a new one?