GNOME Bugzilla – Bug 357662
[xvid] crashes when seeking
Last modified: 2009-01-29 11:21:56 UTC
Version: 2.16.1 What were you doing when the application crashed? attempted to rewind while watching a video. When I started watching the video the file had not completely downloaded. At the time of the attempted rewind it had been fully downloaded however. Distribution: Ubuntu 6.10 (edgy) Gnome Release: 2.16.0 2006-09-04 (Ubuntu) BugBuddy Version: 2.16.0 Memory status: size: 181280768 vsize: 0 resident: 181280768 share: 0 rss: 67915776 rss_rlim: 0 CPU usage: start_time: 1159203050 rtime: 0 utime: 107426 stime: 0 cutime:103737 cstime: 0 timeout: 3689 it_real_value: 0 frequency: 3 Backtrace was generated from '/usr/bin/totem' (no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1225951568 (LWP 19870)] [New Thread -1336050784 (LWP 26187)] [New Thread -1249236064 (LWP 26185)] [New Thread -1282245728 (LWP 26184)] [New Thread -1327658080 (LWP 26183)] [New Thread -1315685472 (LWP 26182)] [New Thread -1264063584 (LWP 25601)] [New Thread -1273594976 (LWP 25599)] [New Thread -1307292768 (LWP 25596)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 73229
Thread 8 (Thread -1273594976 (LWP 25599))
Thanks for the bug report. This is _probably_ fixed in gst-plugins-bad CVS. However, it would still be great if you could try to reproduce the crash and get a stack trace with debugging symbols, so we can make sure. Please install the following packages to get debugging symbols for GStreamer: $ sudo apt-get install libgstreamer0.10-0-dbg gstreamer0.10-plugins-base-dbg gstreamer0.10-plugins-good-dbg gstreamer0.10-plugins-ugly-multiverse-dbg gstreamer0.10-plugins-bad-multiverse-dbg (Use just 'gstreamer0.10-plugins-bad-dbg gstreamer0.10-plugins-ugly-dbg' if you don't have the -multiverse varieties installed). (After you have gotten a new stack trace with debugging symbols, you might want to also install the gstreamer0.10-ffmpeg package - it generally provides better mpeg4/xvid decoding than xviddec).
Attempts to replicate the previous behaviour with debug sybols enabled keep failing. I can get totem to crash (freezes and stops responding), it just won't die and call bug buggy. How do you obtaining a stack trace for a program that is still running, but has frozen and won't respond? Thanks for the tip on ffmpeg, I thought I had it installed already, my mistake.
Something like: $ pidof -s totem <PID> $ gdb -p <PID> Welcome to gdb bla bla bla (gdb) thread apply all bt ... copy'n'paste all output from here .. (gdb) kill (gdb) quit You could also run totem in gdb from the start, like: $ gdb --args /usr/bin/totem foo.avi ... (gdb) run ... wait for crash or Control-C to interrupt .. (gdb) thread apply all bt ... copy'n'paste all output from here ..
Ok, forward-wind 3 time, backwards once and it'll freeze on an uncomplete file. Here is the stack trace:
+ Trace 73324
Thread 1 (Thread -1225988432 (LWP 14701))
This looks like the usual 'the-xvid-decoder-in-bad-isn't-very-stable'. xviddec's rank has been set to NONE in CVS for now so it's not autoplugged any longer. I suggest you install gstreamer0.10-ffmpeg for mpeg4/xvid/divx decoding. Moving to GStreamer. Could you please install gstreamer0.10-plugins-bad-dbg (and or -bad-multiverse-dbg), so that we can get a decent stack trace for the xviddec bits? (The fact that the AVI was fully downloaded when you seeked probably doesn't matter, avidemux will probably just use the size it found the movie to be at the start and won't keep updating that as the file grows).
*** Bug 357673 has been marked as a duplicate of this bug. ***
Actually, this seems to happen a lot when seeking in general, so changing bug title accordingly.
*** Bug 448951 has been marked as a duplicate of this bug. ***
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!