Bug 578731 – Python plugin loader deadlocks registry scanning

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 578731 - Python plugin loader deadlocks registry scanning


Summary:	Python plugin loader deadlocks registry scanning


Status:	RESOLVED FIXED

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

Importance:	Normal blocker
Target Milestone:	0.10.15
Assigned To:	GStreamer Maintainers
QA Contact:	GStreamer Maintainers

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2009-04-12 00:32 UTC by René Stadler
Modified:	2009-04-12 19:28 UTC

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

Description René Stadler 2009-04-12 00:32:13 UTC

Looks like the fix for bug #576145 has a little caveat. I couldn't help but notice that my gst git setup is hanging on registry update. Looks like the python plugin now recursively tries to build the registry?! gdb --args gst-inspect-0.10 --disable-registry-fork backtrace:

+ Trace 214386

Thread 1 (Thread 0x7f4bac1aa6e0 (LWP 10794))

#0 __lll_lock_wait
from /lib/libpthread.so.0
#1 _L_lock_102
from /lib/libpthread.so.0
#2 pthread_mutex_lock
from /lib/libpthread.so.0
#3 gst_plugin_load_file
at gstplugin.c line 466
#4 gst_registry_scan_path_level
at gstregistry.c line 919
#5 gst_registry_scan_path
at gstregistry.c line 955
#6 scan_and_update_registry
at gst.c line 724
#7 ensure_current_registry
at gst.c line 790
#8 gst_update_registry
at gst.c line 1596
#9 _wrap_gst_update_registry
at gst.c line 23364
#10 PyEval_EvalFrameEx
from /usr/lib/libpython2.5.so.1.0
#11 PyEval_EvalCodeEx
from /usr/lib/libpython2.5.so.1.0
#12 PyEval_EvalCode
from /usr/lib/libpython2.5.so.1.0
#13 PyImport_ExecCodeModuleEx
from /usr/lib/libpython2.5.so.1.0
#14 ??
from /usr/lib/libpython2.5.so.1.0
#15 ??
from /usr/lib/libpython2.5.so.1.0
#16 ??
from /usr/lib/libpython2.5.so.1.0
#17 ??
from /usr/lib/libpython2.5.so.1.0
#18 ??
from /usr/lib/libpython2.5.so.1.0
#19 PyImport_ImportModuleLevel
from /usr/lib/libpython2.5.so.1.0
#20 ??
from /usr/lib/libpython2.5.so.1.0
#21 PyObject_Call
from /usr/lib/libpython2.5.so.1.0
#22 PyObject_CallFunctionObjArgs
from /usr/lib/libpython2.5.so.1.0
#23 PyImport_Import
from /usr/lib/libpython2.5.so.1.0
#24 PyImport_ImportModule
from /usr/lib/libpython2.5.so.1.0
#25 plugin_init
at gstpythonplugin.c line 276
#26 gst_plugin_register_func
at gstplugin.c line 342
#27 gst_plugin_load_file
at gstplugin.c line 553
#28 gst_registry_scan_path_level
at gstregistry.c line 919
#29 gst_registry_scan_path
at gstregistry.c line 955
#30 scan_and_update_registry
at gst.c line 724
#31 ensure_current_registry
at gst.c line 790
#32 init_post
at gst.c line 1112
#33 IA__g_option_context_parse
at /build/buildd/glib2.0-2.18.2/glib/goption.c line 1796
#34 main
at gst-inspect.c line 1428

Comment 1 Edward Hervey 2009-04-12 08:56:06 UTC

ouch :( I'm trying to add a detection in __init__.py to avoid recursive registry loading.

Comment 2 Edward Hervey 2009-04-12 09:14:40 UTC

This also seems to happen only if there's changes in plugins different from the gstpython one.

Comment 3 Edward Hervey 2009-04-12 19:28:46 UTC

commit bbedab4e6521fe7c813f23698fe650203b1d0820
Author: Edward Hervey <bilboed@bilboed.com>
Date:   Sun Apr 12 21:27:33 2009 +0200

    registry: fix deadlock with recursive registry scanning.
    
    The way to properly fix this issue was in fact to disable the registry
    scanning when we import gst from the python plugin loader since...
    we are 100% guaranteed this is being called from a registry scan :)