After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 669827 - [pitivi] [ges] Inserting at the end of the timeline sometimes deadlocks
[pitivi] [ges] Inserting at the end of the timeline sometimes deadlocks
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-editing-services
0.10.35
Other Linux
: Normal normal
: 1.2.0
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-02-10 18:58 UTC by Jean-François Fortin Tam
Modified: 2013-09-24 16:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gdb output (107.97 KB, text/plain)
2012-02-10 18:58 UTC, Jean-François Fortin Tam
Details
gdb output from all threads (377.09 KB, text/plain)
2012-02-12 15:16 UTC, Jean-François Fortin Tam
Details

Description Jean-François Fortin Tam 2012-02-10 18:58:58 UTC
Created attachment 207287 [details]
gdb output

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.
Comment 1 Vincent Penquerc'h 2012-02-12 12:41:46 UTC
GES seems the likeliest, at least to investigate, assigning to it for now.
Comment 2 Jean-François Fortin Tam 2012-02-12 15:16:28 UTC
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.
Comment 3 Jean-François Fortin Tam 2012-04-24 00:40:54 UTC
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
Comment 4 Jean-François Fortin Tam 2013-01-30 18:22:52 UTC
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.