| Summary: | telepathy-glib: release connections' object paths before their bus names, and do both sooner | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | Simon McVittie <smcv> |
| Component: | tp-glib | Assignee: | Simon McVittie <smcv> |
| Status: | RESOLVED FIXED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | robert, vivek |
| Version: | unspecified | Keywords: | patch |
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://git.collabora.co.uk/?p=user/smcv/telepathy-glib-smcv.git;a=shortlog;h=refs/heads/disappear | ||
| Whiteboard: | review+ | ||
| i915 platform: | i915 features: | ||
Reassigning to the mailing list, I'm not going to be doing this any time soon. Now that dbus-glib has had 3.5 years of sporadic development and even some new features, we can do this much easier, while simultaneously fixing a bug Vivek reported on IRC in which a lingering connection can cause a new connection attempt to crash. Branch: http://git.collabora.co.uk/?p=user/smcv/telepathy-glib-smcv.git;a=shortlog;h=refs/heads/disappear However, merging this breaks the Gabble regression tests, because sidecars.py expects a particular error. So, we'll need this, which can be merged at any time: http://git.collabora.co.uk/?p=user/smcv/telepathy-gabble-smcv.git;a=shortlog;h=refs/heads/test (In reply to comment #3) > However, merging this breaks the Gabble regression tests, because sidecars.py > expects a particular error. So, we'll need this, which can be merged at any > time: > > http://git.collabora.co.uk/?p=user/smcv/telepathy-gabble-smcv.git;a=shortlog;h=refs/heads/test ... but imagine it's on the 0.10 branch (I'll cherry-pick). (In reply to comment #3) > However, merging this breaks the Gabble regression tests, because sidecars.py > expects a particular error. I fixed that in telepathy-gabble-0.10 and master, for 0.10.5 and 0.11.0 respectively, so no need to review my 'test' branch now. Reviewd, tested in env where recent bug report arose, looks good and seems to DTRT. Fixed in git for 0.13.5, thanks! I don't think this should be backported to 0.12, since it's a visible behaviour change to fix a relatively unlikely bug. |
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.
16:53 < mikhailz> there should be a way in every binding to unregister the object path while the object is still around ... 16:54 < mikhailz> smcv: dbus-glib has the same problem, only we can make the destruction gap almost predictably small 16:54 < smcv> sorry? I don't follow 16:55 < smcv> oh, you're referring to the need to synchronize release of the object path and of the bus name? 16:55 < mikhailz> smcv: there is a short time interval between releasing the bus name and destroying the object path 16:55 < smcv> I know 16:56 < smcv> ideally the destruction needs to take place in the opposite order 16:56 < smcv> effectively, using the bus name as a mutex 16:56 < smcv> since failing to obtain a bus name fails gracefully, whereas trying to reuse an object path triggers scary warnings and/or assertions 16:56 < smcv> as I said, libdbus hates us ... 16:57 < mikhailz> hm, that gives me an idea for the GLib implementation, release the bus name in the "afterlife" callback 16:58 < smcv> mikhailz: do you mean finalize as opposed to dispose? 16:59 < smcv> even the approach I use in dbus-python isn't perfect; there's something that can fail (OOM at exactly the wrong moment, I think) that causes me to leak 1 string's worth of memory 16:59 < mikhailz> smcv: no, in the idle callback or something similar