totem crash while seeking in WM9 video

[Sitsofe Wheeler]

Binary package hint: gstreamer0.10-ffmpeg

Description of the problem:
Seeking repeatedly within t_mgs4_e35.wmv eventually causes totem to crash (although apport is mysteriously not started).

Steps to reproduce:
1. Download and save
http://trailers.gametrailers.com/gt_vault/t_mgs4_e35.wmv
2. Open t_mgs4_e35.wmv within totem .
3. Hold down the middle mouse button while dragging the slider back and forth between 25%-75%. Periodically let go of the middle mouse button then hold it down again during the process.

Expected results:
Video to jump to chosen location and to start playing.

Actual results:
Video pauses for quite long periods and totem will eventually crash.

How reproducible is the problem:
The problem is reproducible every time but can be awkward to trigger.

Additional information:
xine does not manifest this problem with the same video.

Version information:
Ubuntu Feisty
gstreamer0.10-ffmpeg 0.10.2-0ubuntu4
gstreamer0.10-plugins-bad 0.10.4-1ubuntu1
gstreamer0.10-plugins-bad-multiverse 0.10.4-3
gstreamer0.10-plugins-base 0.10.11.4-0ubuntu1
gstreamer0.10-plugins-base-apps 0.10.11.4-0ubuntu1
gstreamer0.10-plugins-good 0.10.5-1ubuntu2
gstreamer0.10-plugins-ugly 0.10.5-0ubuntu2

[Sitsofe Wheeler (sitsofe)]

Forgot to add:
totem 2.17.92-0ubuntu3
totem-gstreamer 2.17.92-0ubuntu3

[Sitsofe Wheeler (sitsofe)]

With the most recent round of gstreamer updates this has become a little harder to reproduce.

gstreamer0.10-ffmpeg 0.10.2-0ubuntu4
gstreamer0.10-plugins-bad 0.10.4-1ubuntu1
gstreamer0.10-plugins-bad-multiverse 0.10.4-3
gstreamer0.10-plugins-base 0.10.12-0ubuntu1
gstreamer0.10-plugins-base-apps 0.10.12-0ubuntu1
gstreamer0.10-plugins-good 0.10.5-1ubuntu2
gstreamer0.10-plugins-ugly 0.10.5-0ubuntu2

Following was printed on the console:
thread 0x8b0dd00 in pool 0x80b83b8 waits for up to a 1/2 second for task (1 running, 0 unprocessed).
thread 0x8b0dd00 in pool 0x80b83b8 calling func.
thread 0x8b0dd00 in pool 0x80b83b8 waits for up to a 1/2 second for task (1 running, 0 unprocessed).
thread 0x8b0dd00 leaving pool 0x80b83b8 for global pool.

** ERROR **: file gstasfdemux.c: line 498 (gst_asf_demux_get_var_length): assertion failed: (*p_size >= 1)
aborting...
Aborted (core dumped)

For some reason apport refuses to start during the crash so I've captured the backtrace the old fashioned way:

(gdb) thread apply all bt

Thread 11 (process 5426):
#0 0xb7f37410 in __kernel_vsyscall ()
#1 0xb737284c in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb7382133 in g_cond_timed_wait_posix_impl (cond=0x8151c00, entered_mutex=0x0, abs_time=0x1b) at gthread-posix.c:242
#3 0xb73f8eda in gst_element_get_state_func (element=0x8407008, state=0x0, pending=0x0, timeout=100000000) at gstelement.c:1802
#4 0xb73e7574 in gst_bin_get_state_func (element=0x8407008, state=0x0, pending=0x0, timeout=100000000) at gstbin.c:1294
#5 0xb73f5894 in gst_element_get_state (element=0x8407008, state=0x0, pending=0x0, timeout=100000000) at gstelement.c:1905
#6 0x0807fae7 in bacon_video_widget_seek_time ()
#7 0x0807fdf0 in bacon_video_widget_seek ()
#8 0x0805f8ed in ?? ()
#9 0x0840c028 in ?? ()
#10 0x3f3b146c in ?? ()
#11 0xbfec8db4 in ?? ()
#12 0x000492b9 in ?? ()
#13 0x00000000 in ?? ()

Thread 10 (process 5428):
#0 0xb7f37410 in __kernel_vsyscall ()
#1 0xb7375986 in ?? () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb71fb002 in IA__g_usleep (microseconds=50000) at gtimer.c:170
#3 0xb5d058c1 in gst_xvimagesink_event_thread (xvimagesink=0x83c8050) at xvimagesink.c:1451
#4 0xb71f8b5f in g_thread_create_proxy (data=0x83d3d10) at gthread.c:591
#5 0xb736e31b in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#6 0xb71313ee in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 9 (process 5430):
#0 0xb7f37410 in __kernel_vsyscall ()
#1 0xb7374ec1 in __lll_mutex_unlock_wake () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb737266f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0
#3 0xb7421d98 in gst_system_clock_async_thread (clock=0x81f16d8) at gstsystemclock.c:260
#4 0xb71f8b5f in g_thread_create_proxy (data=0x83df4c8) at gthread.c:591
#5 0xb736e31b in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#6 0xb71313ee in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 8 (process 5434):
#0 0xb7f37410 in __kernel_vsyscall ()
#1 0xb73725c6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb5d24b2f in gst_queue_loop (pad=0x845fcb8) at gstqueue.c:885
#3 0xb742...

[Sitsofe Wheeler (sitsofe)]

Try as I might, I could not reproduce this in totem on Gutsy. Resolve fixed?

[Sitsofe Wheeler (sitsofe)]

Still seems fixed in Hardy. Resolving fixed.