Bug 752300 – After updating GES from 1.5.2 to Master complex timelines makes whole app to hang

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 752300 - After updating GES from 1.5.2 to Master complex timelines makes whole app to hang


Summary:	After updating GES from 1.5.2 to Master complex timelines makes whole app to ...


Status:	RESOLVED FIXED

Product:	GStreamer
Classification:	Platform
Component:	gst-editing-services
Version:	git master
Hardware:	Other Linux

Importance:	Normal normal
Target Milestone:	1.5.90
Assigned To:	GStreamer Maintainers
QA Contact:	GStreamer Maintainers

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2015-07-12 22:29 UTC by Kyrylo V. Polezhaiev
Modified:	2015-08-16 13:37 UTC

See Also:
GNOME target:	---
GNOME version:	---

Attachments
assets: Avoid deadlock when setting done initialising asset (1.41 KB, patch) 2015-07-13 11:51 UTC, Thibault Saunier	none	Details \| Review
assets: Avoid deadlock when done initialising asset (1.41 KB, patch) 2015-07-13 11:55 UTC, Thibault Saunier	committed	Details \| Review

Description Kyrylo V. Polezhaiev 2015-07-12 22:29:00 UTC

Reproducible using ges-launch-1.0.
Will prepare .XGES soon.

+ Trace 235253

#0 __lll_lock_wait
from /usr/lib64/libpthread.so.0
#1 _L_lock_975
from /usr/lib64/libpthread.so.0
#2 pthread_mutex_lock
from /usr/lib64/libpthread.so.0
#3 g_mutex_lock
from /usr/lib64/libglib-2.0.so.0
#4 ges_asset_cache_lookup
at ges-asset.c line 449
#5 ges_asset_request
at ges-asset.c line 731
#6 create_transition
at ges-timeline.c line 819
#7 _create_transitions_on_layer
at ges-timeline.c line 994
#8 layer_auto_transition_changed_cb
at ges-timeline.c line 2196
#9 g_closure_invoke
from /usr/lib64/libgobject-2.0.so.0
#10 signal_emit_unlocked_R
from /usr/lib64/libgobject-2.0.so.0
#11 g_signal_emit_valist
from /usr/lib64/libgobject-2.0.so.0
#12 g_signal_emit
from /usr/lib64/libgobject-2.0.so.0
#13 g_object_dispatch_properties_changed
from /usr/lib64/libgobject-2.0.so.0
#14 g_object_notify
from /usr/lib64/libgobject-2.0.so.0
#15 ges_layer_set_auto_transition
at ges-layer.c line 424
#16 ges_timeline_set_auto_transition
at ges-timeline.c line 3435
#17 _loading_done
at ges-base-xml-formatter.c line 470
#18 new_asset_cb
at ges-base-xml-formatter.c line 765
#19 g_task_return_now
from /usr/lib64/libgio-2.0.so.0
#20 g_task_return
from /usr/lib64/libgio-2.0.so.0
#21 _gtask_return_true
at ges-asset.c line 429
#22 g_list_foreach
from /usr/lib64/libglib-2.0.so.0
#23 ges_asset_cache_set_loaded
at ges-asset.c line 514
#24 discoverer_discovered_cb
at ges-uri-asset.c line 365
#25 ffi_call_unix64
from /usr/lib64/libffi.so.6
#26 ffi_call
from /usr/lib64/libffi.so.6

Comment 1 Kyrylo V. Polezhaiev 2015-07-12 22:38:29 UTC

works in tag 1.5.2, not works in master

Comment 2 Thibault Saunier 2015-07-13 08:29:06 UTC

OK, weird, I have never seen that. Please provide a way to reproduce or at least a full backtrace.

Comment 3 Kyrylo V. Polezhaiev 2015-07-13 08:46:05 UTC

I will try to provide a way to reproduce tonight. However, I attached backtrace to first message (description). It is g_mutex_lock call from ges_asset_cache_lookup function at ges-asset.c line 449.

Comment 4 Thibault Saunier 2015-07-13 11:44:37 UTC

I need to figure out where the lock is taken... that is why I need a trace with all threads.

Comment 5 Thibault Saunier 2015-07-13 11:51:11 UTC

Created attachment 307338 [details] [review]
assets: Avoid deadlock when setting done initialising asset

Avoid to hold the CACHE lock when setting the GTasks return values.

Fixes

Comment 6 Thibault Saunier 2015-07-13 11:55:05 UTC

Created attachment 307339 [details] [review]
assets: Avoid deadlock when done initialising asset

Avoid to hold the CACHE lock when setting the GTasks return values.

Fixes

Comment 7 Thibault Saunier 2015-07-13 13:38:31 UTC

@Kyrylo: Can you double check that fixes the issue?

Comment 8 Kyrylo V. Polezhaiev 2015-07-13 16:31:06 UTC

Yes, I will do this tonight.

Comment 9 Kyrylo V. Polezhaiev 2015-07-15 11:33:01 UTC

Agrrrr, this patches aren't applicable one by one.

Comment 10 Kyrylo V. Polezhaiev 2015-07-15 11:34:50 UTC

Oh, understood. I should only apply second one.

Comment 11 Kyrylo V. Polezhaiev 2015-07-15 11:38:19 UTC

No more deadlocks, thank you Thibault. Patch #2 works fine.

Comment 12 Kyrylo V. Polezhaiev 2015-07-15 12:02:39 UTC

Review of attachment 307339 [details] [review]:

This patch works for me. Have no deadlocks anymore.

Comment 13 Thibault Saunier 2015-07-15 12:51:08 UTC

Attachment 307339 [details] pushed as 724418b - assets: Avoid deadlock when done initialising asset