| Summary: | Segfault in _dbus_connection_lock() | ||
|---|---|---|---|
| Product: | dbus | Reporter: | Nikolay Kovalenko <nkoval> |
| Component: | core | Assignee: | Havoc Pennington <hp> |
| Status: | RESOLVED NOTOURBUG | QA Contact: | John (J5) Palmieri <johnp> |
| Severity: | normal | ||
| Priority: | medium | CC: | name29 |
| Version: | 1.3.x (devel) | Keywords: | NEEDINFO |
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | might really be #38005 | ||
| i915 platform: | i915 features: | ||
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. 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.
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.