Bug 29663 - obexd 0.29 can't start because of an assert in DBus-Glib is triggered.
Summary: obexd 0.29 can't start because of an assert in DBus-Glib is triggered.
Status: RESOLVED DUPLICATE of bug 30574
Alias: None
Product: dbus
Classification: Unclassified
Component: GLib (show other bugs)
Version: 1.2.x
Hardware: x86 (IA32) All
: medium blocker
Assignee: Rob Taylor
QA Contact: John (J5) Palmieri
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-18 23:30 UTC by Zhu Yanhai
Modified: 2011-04-20 08:30 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Remove a wrong assertion. (353 bytes, patch)
2010-08-18 23:30 UTC, Zhu Yanhai
Details | Splinter Review

Description Zhu Yanhai 2010-08-18 23:30:42 UTC
Created attachment 37968 [details] [review]
Remove a wrong assertion.

(Please ref to http://bugs.meego.com/show_bug.cgi?id=5408 for more details)

When starting obexd 0.29 (which will call into libebook in evolution-data-server), it reported:

obexd[1557]: OBEX daemon 0.29
**
ERROR:dbus-gmain.c:253:connection_setup_add_watch: assertion failed:
(dbus_watch_get_data (watch) == NULL)
Aborted (core dumped)

The assertion in dbus-gmain.c:253 said dbus_watch_get_data (watch) should be
NULL, however connection_setup_add_watch will call into dbus_watch_set_data then, it will free watch->data if watch->free_data_function exists, which conflicts with the assertion.

Using gdb to following its execution, when the assertion failed, I found
watch->data was not NULL and watch->free_data_function was pointing to watch_info_free(), which was able to free watch->data.

So I guess the assertion is wrong. Patch attached. Thanks.
Comment 1 Simon McVittie 2010-09-28 10:22:25 UTC
Please be very careful when removing assertions: presumably someone added them for a reason.

By checking that the data is NULL, I think connection_setup_add_watch is essentially checking that the watch hasn't already been added? Because io_handler_destroy_source removes the GSource, it might be OK to "migrate" a DBusWatch from one GSource to another, which I think is what will happen here if the assertion is removed... or it might not be OK, I can't tell immediately.

Perhaps it's appropriate to remove the assertion, or perhaps connection_setup_add_watch should do nothing and just return if the watch already has an IOHandler, or perhaps the assertion failure indicates a bug elsewhere in dbus-glib and/or the application: the mere fact that the assertion failed doesn't particularly imply any of these.
Comment 2 Simon McVittie 2011-04-20 08:30:48 UTC
Mike Gorse fixed this in 0.90.

*** This bug has been marked as a duplicate of bug 30574 ***


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.