On Fri, Apr 8, 2011 at 9:09 AM, Andrew Wason <[email protected]> wrote: > Since locking was added to kdenlive/filter_freeze.c (commit > b698c58e57643e9df6941d91b07a40c997bd7e64), it now deadlocks. > > A simple mlt xml file is attached that reproduces the problem.
Thanks, fixed. > filter_freeze is recursively locking it's filter service mutex, and so > the second lock blocks forever. > > The deadlocked stack trace is below. filter_freeze filter_get_image() > locks the mutex, then calls mlt_frame_get_image() on the freeze_frame > it got from the producer, which calls into filter_freeze > filter_get_image() again which attempts to relock the mutex and > deadlocks. > > It seems like the problem is when filter_freeze gets the frame from > its producer, it is getting the filtered frame instead of the raw > frame from the producer because mlt_service_get_frame() applies > filters. Should filter_freeze be getting the freeze_frame directly > from the producer, unfiltered, by calling producer->get_frame() > directly instead of mlt_service_get_frame()? But it seems like we > would want other filters to apply, just not filter_freeze itself. > > Or maybe just allow mutexes to be recursively locked (initialize them > with PTHREAD_MUTEX_RECURSIVE)? > > #0 0x00007ffff79a3464 in __lll_lock_wait () from /lib/libpthread.so.0 > #1 0x00007ffff799e5d9 in _L_lock_953 () from /lib/libpthread.so.0 > #2 0x00007ffff799e3fb in pthread_mutex_lock () from /lib/libpthread.so.0 > #3 0x00007ffff7bc4db5 in mlt_service_lock (self=0x6cf120) at > mlt_service.c:137 > #4 0x00007fffefeb73ee in filter_get_image (this=0x6dcd50, > image=0x7fffffffdb98, format=0x7fffffffdf0c, width=0x7fffffffdf08, > height=0x7fffffffdf04, writable=1) at filter_freeze.c:53 > #5 0x00007ffff7bbc4c9 in mlt_frame_get_image (self=0x6dcd50, > buffer=0x7fffffffdb98, format=0x7fffffffdf0c, width=0x7fffffffdf08, > height=0x7fffffffdf04, writable=1) at mlt_frame.c:453 > #6 0x00007fffefeb7601 in filter_get_image (this=0x6d7fe0, > image=0x7fffffffdef0, format=0x7fffffffdf0c, width=0x7fffffffdf08, > height=0x7fffffffdf04, writable=0) at filter_freeze.c:77 > #7 0x00007ffff7bbc4c9 in mlt_frame_get_image (self=0x6d7fe0, > buffer=0x7fffffffdef0, format=0x7fffffffdf0c, width=0x7fffffffdf08, > height=0x7fffffffdf04, writable=0) at mlt_frame.c:453 > #8 0x00007ffff7bd0d68 in producer_get_image (self=0x68adb0, > buffer=0x7fffffffdef0, format=0x7fffffffdf0c, width=0x7fffffffdf08, > height=0x7fffffffdf04, writable=0) at mlt_tractor.c:275 > [...] > > Hmm, actually a workaround seems to be to set in="1" on the freeze > filter - so since we are freezing frame 0 that frame is then not > filtered through freeze again. > > Andrew > > ------------------------------------------------------------------------------ > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > _______________________________________________ > Mlt-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mlt-devel > > -- +-DRD-+ ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ Mlt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mlt-devel
