Bug 199617 - dbus trips "!(connection)->have_connection_lock" assert and aborts
dbus trips "!(connection)->have_connection_lock" assert and aborts
Product: Fedora
Classification: Fedora
Component: dbus (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: John (J5) Palmieri
: 199593 199596 199603 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2006-07-20 15:19 EDT by Michal Jaegermann
Modified: 2013-03-13 00:51 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-07-22 19:09:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2006-07-20 15:19:14 EDT
Description of problem:

The lastest dbus updates make a system quite unhappy.  Some daemons
refuse to run and gnome-session does not start (blank screen with
a working mouse pointer and that is it).  With some "debuginfo" packages
loaded one can see, for example the following from 'gdb hald' run with
'--daemon=no --verbose=yes' arguments:

13:23:12.382 [I] coldplug.c:268: found device_file /dev/dm-1 for sysfs_path
13:23:12.382 [I] osspec.c:517: Synthesizing powermgmt events...
13:23:12.383 [I] acpi.c:768: Processing /proc/acpi/processor/CPU1
13:23:12.383 [E] acpi.c:795: Couldn't open /proc/acpi/button/lid: Error opening
directory '/proc/acpi/button/lid': No such file or directory
13:23:12.383 [I] acpi.c:768: Processing /proc/acpi/button/power/PWRB
13:23:12.383 [I] acpi.c:768: Processing /proc/acpi/button/power/PWRF
13:23:12.383 [I] acpi.c:768: Processing /proc/acpi/button/sleep/SLPB
13:23:12.384 [I] osspec.c:519: ACPI capabilities found
13:23:12.384 [I] osspec.c:529: Done synthesizing events
17614: assertion failed "!(connection)->have_connection_lock" file
"dbus-connection.c" line 1727 function dbus_connection_ref

Program received signal SIGABRT, Aborted.
0x0000003c48a33145 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x0000003c48a33145 in raise () from /lib64/libc.so.6
#1  0x0000003c48a34a90 in abort () from /lib64/libc.so.6
#2  0x00002aaaaad2ccc5 in _dbus_abort () at dbus-sysdeps.c:89
#3  0x00002aaaaad1a377 in _dbus_real_assert (condition=<value optimized out>,
    condition_text=0x2aaaaad2ff38 "!(connection)->have_connection_lock",
    file=0x2aaaaad2f9de "dbus-connection.c", line=1727,
    func=0x2aaaaad31c30 "dbus_connection_ref") at dbus-internals.c:477
#4  0x00002aaaaaceeb9a in dbus_connection_ref (connection=0x644b60)
    at dbus-connection.c:1727
#5  0x00002aaaaad0c51c in _dbus_pending_call_new (connection=0x644b60,
    timeout_milliseconds=<value optimized out>,
    timeout_handler=0x2aaaaacf61c0 <reply_handler_timeout>)
    at dbus-pending-call.c:122
#6  0x00002aaaaacf5bd8 in dbus_connection_send_with_reply (
    connection=0x644b60, message=0x670820, pending_return=0x7fff3fc65e38,
    timeout_milliseconds=2147483647) at dbus-connection.c:2396
#7  0x000000000040762d in hald_runner_run_method (device=0x647a10,
    command_line=0x429353 "hald-probe-smbios", extra_env=0x0,
    input=0x427878 "", error_on_stderr=0, timeout=10000,
    cb=0x414600 <computer_probing_pcbios_helper_done>, data1=0x0, data2=0x0)
    at hald_runner.c:357
#8  0x0000000000407777 in hald_runner_run (device=0x44ce,
    command_line=0x44ce <Address 0x44ce out of bounds>, extra_env=0x6,
    timeout=1219574880, cb=<value optimized out>, data1=<value optimized out>,
    data2=0x0) at hald_runner.c:384
#9  0x0000000000414421 in osspec_probe () at osspec.c:541
#10 0x000000000040d1da in main (argc=<value optimized out>,
    argv=0x7fff3fc664b8) at hald.c:576
#11 0x0000003c48a20aa4 in __libc_start_main () from /lib64/libc.so.6
#12 0x00000000004055e9 in _start ()

See also bug #199593 and bug #199596.  The later has a similar backtrace
from avahi-daemon.

Version-Release number of selected component (if applicable):

How reproducible:

Additional info:
This was observed on x86_64 but on fedora-test-list similar sightings
were reported also on i686 system
Comment 1 John (J5) Palmieri 2006-07-20 16:34:59 EDT
Yep, silly me tried to grab a ref when the connection was locked.  I've added a
patch to use _dbus_connection_ref_unlocked instead.  I'm going to test after my
massive update finishes and then build in rawhide.
Comment 2 John (J5) Palmieri 2006-07-20 16:36:12 EDT
*** Bug 199603 has been marked as a duplicate of this bug. ***
Comment 3 John (J5) Palmieri 2006-07-20 16:37:20 EDT
*** Bug 199593 has been marked as a duplicate of this bug. ***
Comment 4 Michal Jaegermann 2006-07-21 11:27:00 EDT
*** Bug 199596 has been marked as a duplicate of this bug. ***
Comment 5 Michal Jaegermann 2006-07-21 11:53:16 EDT
dbus updates indeed fix the problem for me.  avahi-daemon and hald are
running again and I have my gnome-session back.  Thanks!  Anything
Comment 6 John (J5) Palmieri 2006-07-21 14:42:46 EDT
*** Bug 199748 has been marked as a duplicate of this bug. ***
Comment 7 David Nielsen 2006-07-22 09:08:27 EDT
With dbus-0.90-7 I'm seeing the dreaded blue screen with only a pointer to guide
me, I thought this was a Windows only feature..
Comment 8 David Nielsen 2006-07-22 09:59:44 EDT
(In reply to comment #7)
> With dbus-0.90-7 I'm seeing the dreaded blue screen with only a pointer to guide
> me, I thought this was a Windows only feature..

My bad, that specific error was caused by the xorg-x11-xinit-1.0.2-7.fc6 update,
downgrading that makes the blue screen go away.

Note You need to log in before you can comment on or make changes to this bug.