Our multi-threaded test application written on Python and using DBus for internal communication between components from time to time crashes with segfault with the backtrace below:
#0 0x0046e462 in _dbus_connection_lock (connection=0x0) at dbus-connection.c:355
#1 0x00483745 in _dbus_pending_call_get_connection_and_lock (pending=0x86580a0) at dbus-pending-call.c:307
#2 0x00473555 in reply_handler_timeout (data=0x86580a0) at dbus-connection.c:3175
#3 0x00488662 in dbus_timeout_handle (timeout=0x8657a18) at dbus-timeout.c:473
#4 0x004e14c0 in timeout_handler_dispatch (data=0x8665340) at dbus-gmain.c:343
#5 0x0036b53c in g_timeout_dispatch (source=0x866efc8, callback=0, user_data=0x8665340) at /build/buildd/glib2.0-2.22.3/glib/gmain.c:3396
#6 0x0036ae88 in g_main_dispatch (context=0x85e8598) at /build/buildd/glib2.0-2.22.3/glib/gmain.c:1960
#7 IA__g_main_context_dispatch (context=0x85e8598) at /build/buildd/glib2.0-2.22.3/glib/gmain.c:2513
#8 0x0036e730 in g_main_context_iterate (context=0x85e8598, block=<value optimized out>, dispatch=1, self=0x85e1b90)
#9 0x0036eb9f in IA__g_main_loop_run (loop=0x85e7768) at /build/buildd/glib2.0-2.22.3/glib/gmain.c:2799
#10 0x002d807a in ?? () from /usr/lib/pymodules/python2.6/gtk-2.0/glib/_glib.so
#11 0x080dbfd5 in call_function (f=0x85933d0, throwflag=0) at ../Python/ceval.c:3690
#12 PyEval_EvalFrameEx (f=0x85933d0, throwflag=0) at ../Python/ceval.c:2389
#13 0x080dd384 in fast_function (f=0x85e6d64, throwflag=0) at ../Python/ceval.c:3792
#14 call_function (f=0x85e6d64, throwflag=0) at ../Python/ceval.c:3727
#15 PyEval_EvalFrameEx (f=0x85e6d64, throwflag=0) at ../Python/ceval.c:2389
#16 0x080dd384 in fast_function (f=0x85e6c04, throwflag=0) at ../Python/ceval.c:3792
#17 call_function (f=0x85e6c04, throwflag=0) at ../Python/ceval.c:3727
#18 PyEval_EvalFrameEx (f=0x85e6c04, throwflag=0) at ../Python/ceval.c:2389
#19 0x080dddf2 in PyEval_EvalCodeEx (co=0xb7ea2e30, globals=0xb7f9446c, locals=0x0, args=0x858df78, argcount=1, kws=0x0, kwcount=0, defs=0x0,
defcount=0, closure=0x0) at ../Python/ceval.c:2968
#20 0x0816014c in function_call (func=0xb7ebeb54, arg=0x858df6c, kw=0x0) at ../Objects/funcobject.c:524
#21 0x0806120a in PyObject_Call (func=0xb7ebeb54, arg=0x858df6c, kw=0x0) at ../Objects/abstract.c:2492
#22 0x080684ac in instancemethod_call (func=0xb7eb970c, arg=0x858df6c, kw=0x0) at ../Objects/classobject.c:2579
#23 0x0806120a in PyObject_Call (func=0xb7eb970c, arg=0xb7f9e02c, kw=0x0) at ../Objects/abstract.c:2492
#24 0x080d6ef2 in PyEval_CallObjectWithKeywords (func=0xb7eb970c, arg=0xb7f9e02c, kw=0x0) at ../Python/ceval.c:3575
#25 0x08107d88 in t_bootstrap (boot_raw=0x82aaa80) at ../Modules/threadmodule.c:425
#26 0x0013380e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#27 0x002578de in clone () from /lib/tls/i686/cmov/libc.so.6
The result was retrieved with this patch — https://bugs.freedesktop.org/attachment.cgi?id=22778. Full core dump is attached to the report.
I found several bugs which are looking similar to this one but I am not sure whether they have the same root cause. Therefore I posted this report. If this problem is well known, already has a patch or another solution I would be glad if you tell me that.
Could not attached core dump to the report, place it here instead: http://www.onlinedisk.ru/file/447088/
Is this still reproducible with 1.4.12 (or a newer 1.4.x release if there is one by the time you re-test), or with 1.5.4 or later? This might have been caused by Bug #38005, for instance.
May be in the first line ( _dbus_connection_lock (connection=0x0) ) pointer to connection invalid ?
So _dbus_connection_lock crash if connection is NULL.
I think that crash is not very good . Exit with error message or what ?
I don't know how patch the code...
(In reply to comment #0)
> Our multi-threaded test application ... using DBus
Best-practice: don't use multi-threading and libdbus. It's extremely error-prone, particularly in older versions.
Crashes in multi-threaded applications might have been caused by Bug #43744 or Bug #38005; upgrading to dbus 1.6.0 or later is recommended.
> #4 0x004e14c0 in timeout_handler_dispatch (data=0x8665340) at
... that looks like dbus-glib. dbus-glib is not thread-safe and I don't think it has ever been safe to use it in multi-threaded applications.
GDBus is a much better choice.