| Summary: | _dbus_watch_invalidate segfaults | ||
|---|---|---|---|
| Product: | dbus | Reporter: | toady |
| Component: | core | Assignee: | Havoc Pennington <hp> |
| Status: | RESOLVED WORKSFORME | QA Contact: | John (J5) Palmieri <johnp> |
| Severity: | critical | ||
| Priority: | medium | CC: | hp, jw+debian, smcv |
| Version: | 1.2.x | Keywords: | NEEDINFO |
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | NB#247014 | ||
| i915 platform: | i915 features: | ||
| Attachments: |
Patch (maybe) resolving this
regression test which doesn't reproduce this bug make modular tests depend on GLib 2.22, for GSocket |
||
|
Description
toady
2008-04-18 02:21:19 UTC
No there is a missing ref on the watch here. We don't clear the watch. It could either be in dbusglib (such as they are unreffing a watch they do not own or are passing off ownership to) or we are not checking if the watch still exists before we invalidate it. looking further, this happens when you get a corrupt message. I still can't figure this out. We ref in dbus-transport-socket.c: _dbus_transport_new_for_socket for the object reference and in dbus-watch.c:_dbus_watch_list_add_watch for the list reference. We then unref in _dbus_watch_list_remove_watch which should leave one more ref. The only thing I can see being an issue is the virtual watch_list->remove_watch_function call. Can you do me a favor and go into gdb and break inside of around line 395 of dbus-watch.c:_dbus_watch_list_remove_watch and see if the function that calls has an unref in it. Thanks. J5 asked for some more information a while ago. Is there some code we can run (a particular program with a particular libnotify version, perhaps) to reproduce this? *** Bug 24412 has been marked as a duplicate of this bug. *** Taking this, I've seen a remarkably similar crash in another project with a patched version of dbus-1.4.6. Created attachment 45662 [details] [review] regression test which doesn't reproduce this bug I was hoping this test would reproduce this bug, but apparently it's not this simple. I think it's still worth committing... Created attachment 45663 [details] [review] make modular tests depend on GLib 2.22, for GSocket Attachment #45662 [details] requires this patch, and the infrastructure from Bug #34570. (In reply to comment #5) > I've seen a remarkably similar crash in another project The other project seems to be invoking dbus_connection_send from a non-main thread without initializing libdbus thread-locking, which seems likely to be what broke it. Could that be the cause here too? The patches here have been applied. Nobody is working on this, so back to NEW. (In reply to comment #8) > (In reply to comment #5) > > I've seen a remarkably similar crash in another project > > The other project seems to be invoking dbus_connection_send from a non-main > thread without initializing libdbus thread-locking, which seems likely to be > what broke it. Could that be the cause here too? Was that the problem here? If so, please resolve as INVALID. (In reply to comment #9) > > The other project seems to be invoking dbus_connection_send from a non-main > > thread without initializing libdbus thread-locking, which seems likely to be > > what broke it. Could that be the cause here too? > > Was that the problem here? If so, please resolve as INVALID. I'm going to assume that that was the case here too. (In reply to comment #6) > Created attachment 45662 [details] [review] > regression test which doesn't reproduce this bug Applied in 2011. (In reply to comment #7) > Created attachment 45663 [details] [review] > make modular tests depend on GLib 2.22, for GSocket > > Attachment #45662 [details] requires this patch, and the infrastructure from > Bug #34570. Applied in 2011. |
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.