Red Hat Bugzilla – Bug 885445
f18/f19/f20 crash in virDBusWatchCallback on i686
Last modified: 2014-01-21 00:55:54 EST
Version-Release number of selected component:
Thread no. 1 (5 frames)
#0 virDBusWatchCallback at util/virdbus.c:144
#1 virEventPollDispatchHandles at util/event_poll.c:485
#2 virEventPollRunOnce at util/event_poll.c:632
#3 virEventRunDefaultImpl at util/event.c:247
#4 virNetServerRun at rpc/virnetserver.c:748
Created attachment 660278 [details]
Created attachment 660279 [details]
Created attachment 660280 [details]
Created attachment 660281 [details]
Created attachment 660282 [details]
Created attachment 660283 [details]
Created attachment 660284 [details]
Created attachment 660285 [details]
Created attachment 660286 [details]
Created attachment 660287 [details]
No more reports of this in 5 months, not clear the cause either, so closing.
It crashed yesterday for me
--- Running report_uReport ---
A bug was already filed about this problem:
ABRT Server: URL=https://retrace.fedoraproject.org/faf/reports/28424/
ABRT Server: URL=https://retrace.fedoraproject.org/faf/reports/bthash/cc974fcd14b0ce5eec2453925117c30dfe380f84
Created attachment 837631 [details]
fc20 still broken. abrt redirected here. attached is var log messages.
Reopening, seems the important bit here is i686 as per the abrt retraces.
(In reply to collura from comment #13)
> Created attachment 837631 [details]
> fc20 still broken. abrt redirected here. attached is var log messages.
collura, can you confirm your f20 package version? what were you doing when this crashed? is it reproducible?
Also, if you could get a fresh backtrace using gnome-abrt, that would help, since the line numbers have changed with f20 libvirt.
What is actually interesting here is that the first report was against 0.10.2.1-3 which included a very relevant dbus patch
Author: Cole Robinson <email@example.com>
Date: Tue Nov 13 08:53:57 2012 -0500
Cleanly save session VMs on logout/shutdown (bz #872254)
From the stack trace we have one thread doing
#8 0x48f384d2 in dbus_connection_set_watch_functions (connection=connection@entry=0xb1300f48, add_function=add_function@entry=0x424cd440 <virDBusAddWatch>, remove_function=remove_function@entry=0x424cd3e0 <virDBusRemoveWatch>, toggled_function=toggled_function@entry=0x424cd370 <virDBusToggleWatch>, data=data@entry=0xb1300f48, free_data_function=free_data_function@entry=0x0) at dbus-connection.c:4898
to initialize the dbus connection. This method will immediately call the 'add_function' function in this case virDBusAddWatch. The event loop is in turn immediately dispatching a watch which triggered causing it to run virDBusWatchCallback
THe stack trace shows that virDBusWatchCallback is crashing on
while (dbus_connection_dispatch(info->bus) == DBUS_DISPATCH_DATA_REMAINS)^M
because 'info' is NULL.
Looking back at the virDBusAddWatch function we have a clear race condition
because we have not yet called dbus_watch_set_data(watch, info, virDBusWatchFree);
Posted a fix for this race
The only unanswered question is why Fedora users are only seeing this on i686. There's nothing really about this code which I can see would be i686 specific - ought to hit x86_64 users too. Perhaps there is just something about the speed (or lack thereof) on i686 which makes the race condition much more likely to hit on i686 ?
( regarding comment#16 about i686 only, here is your x86_64 example ;')
running on a toshiba satellite L75D-A7283 which is chock full of lag :'| )
no hasnt happened again and dont know how to cause it yet.
i think i was using web browser.
every few minutes gnome-shell seemed to die for about 30seconds of blackscreen and then came back. one of the times i checked abrt and found this crash listed but when i reported it there wasnt much info and it sent me on my way. it referenced this then-closed bug (bz#885445)
'--- Running report_uReport ---
A bug was already filed about this problem:
and gave an abrt server entry (which i didnt include in comment#13 because i thought that it did it already doh):
libvirt-188.8.131.52-1.fc20 has been submitted as an update for Fedora 20.
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libvirt-184.108.40.206-1.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
libvirt-220.127.116.11-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.