GNOME Bugzilla – Bug 575068
[mp3parse] deadlock with accurate seeking
Last modified: 2009-03-12 15:23:52 UTC
I'm seeing this deadlock seeking in mp3 files with pitivi git and -ugly git (gdb) info threads 7 Thread 0x42537950 (LWP 26984) 0x00007f5d62ca52d9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 6 Thread 0x41672950 (LWP 26994) 0x00007f5d62ca555d in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 5 Thread 0x40a04950 (LWP 26995) 0x00007f5d62ca52d9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 4 Thread 0x43539950 (LWP 26997) 0x00007f5d62ca52d9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 3 Thread 0x42d38950 (LWP 26998) 0x00007f5d62ca52d9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 2 Thread 0x43d3a950 (LWP 26999) 0x00007f5d62ca7b04 in __lll_lock_wait () from /lib/libpthread.so.0 1 Thread 0x7f5d630b66e0 (LWP 26977) 0x00007f5d62ca7b04 in __lll_lock_wait () from /lib/libpthread.so.0 (gdb) thr a a bt
+ Trace 213409
Thread 1 (Thread 0x7f5d630b66e0 (LWP 26977))
there's a race acquiring mp3parse->pending_accurate_seeks_lock. It's acquired from both the seeking thread and the streaming thread. The deadlock happens when a seek happens; the lock is taken; in the meantime the streaming thread tries to acquire it too but it's taken so the streaming thread blocks; basesrc flushes and waits for the streaming thread to stop -> BOOM
Created attachment 130507 [details] [review] fix
Marking this as a blocker, since it's a regression since last -ugly release.
This looks wrong to me: 1) The 'seek' structure is added to the accurate seek list within the lock, and then modified in the if (send_event() == TRUE) clause without the lock held. 2) If the send_event fails, the seek structure is freed, and a pointer to the freed memory is left in the pending_accurate_seeks list, waiting to make things go kaboom later.
Created attachment 130522 [details] [review] fix 2 oops. Now i remove seek from the list. It should be safe afaics.
Created attachment 130523 [details] [review] also change the seek variable while the lock is held
Looks healthier to me, yip. Please commit.
same here. commit !