GNOME Bugzilla – Bug 669827
[pitivi] [ges] Inserting at the end of the timeline sometimes deadlocks
Last modified: 2013-09-24 16:03:33 UTC
Created attachment 207287 [details]
With the GES version of pitivi, it is possible to cause a deadlock when inserting at the end of the timeline repeatedly (it sometimes happens, sometimes not).
1. Load the project from bug #669826 (or simply create a new project and import a clip)
2. Select the clip in the pitivi media library
3. Press the Insert button on the keyboard until a deadlock occurs and the UI becomes unresponsive.
The following is what the user sees in the terminal:
application.py:257: Warning: value "-1" of type `gint64' is invalid or out of range for property `duration' of type `gint64'
(pitivi:5608): GStreamer-CRITICAL **: gst_segment_set_seek: assertion `start <= stop' failed
Attached is a gdb trace.
GES seems the likeliest, at least to investigate, assigning to it for now.
Created attachment 207394 [details]
gdb output from all threads
Same thing, with "thread apply all bt".
A better trick to ensure easy reproduction of the bug is to hold down the Insert button, which will rapidly and repeatedly insert the clip at the end of the timeline, eventually hitting the deadlock.
I don't seem to be hitting a "deadlock" as I used to now, what I get is that eventually pitivi crashes, even if my RAM is not full yet. Once, it crashed the whole X server with it. This is what I get in the terminal eventually:
(pitivi:31961): GStreamer-CRITICAL **:
Trying to dispose element queue253, but it is in READY instead of the NULL state.
You need to explicitly set elements to the NULL state before
dropping the final reference, to allow them to clean up.
This problem may also be caused by a refcounting bug in the
application or some element.
GThread-ERROR **: file gthread-posix.c: line 171 (g_mutex_free_posix_impl): error 'Device or resource busy' during 'pthread_mutex_destroy ((pthread_mutex_t *) mutex)'
Trappe pour point d'arrêt et de trace
The move to GES Assets means we do not re-discover clips, as we keep internal references to them as "assets".
Now, pressing and holding the Insert button on a 17 seconds clip to repeatedly insert it in the pitivi timeline results in a timeline that is 2 hours and 42 minutes long, which means 572 instances of the clip... without crashing or deadlocking.
Since we don't rediscover on insertion, even if there is still a race condition bug present in the discoverer, we won't be able to trigger it that way. So this particular issue is fixed.