Bug 28340 - Segfault in _dbus_connection_lock()
Summary: Segfault in _dbus_connection_lock()
Status: RESOLVED NOTOURBUG
Alias: None
Product: dbus
Classification: Unclassified
Component: core (show other bugs)
Version: 1.3.x (devel)
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Havoc Pennington
QA Contact: John (J5) Palmieri
URL:
Whiteboard: might really be #38005
Keywords: NEEDINFO
Depends on:
Blocks:
 
Reported: 2010-06-01 01:22 UTC by Nikolay Kovalenko
Modified: 2013-08-27 16:48 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Attachments

Description Nikolay Kovalenko 2010-06-01 01:22:29 UTC 
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)
    at /build/buildd/glib2.0-2.22.3/glib/gmain.c:2591
#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.
Comment 1 Nikolay Kovalenko 2010-06-01 01:31:53 UTC 
Could not attached core dump to the report, place it here instead: http://www.onlinedisk.ru/file/447088/
Comment 2 Simon McVittie 2011-06-14 02:20:37 UTC 
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.
Comment 3 name29 2011-10-28 10:30:51 UTC 
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...
Comment 4 Simon McVittie 2013-08-27 16:48:35 UTC 
(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.

However...

> #4  0x004e14c0 in timeout_handler_dispatch (data=0x8665340) at
> dbus-gmain.c:343

... 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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.