After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 743990 - GDBus connection closing is broken
GDBus connection closing is broken
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gdbus
unspecified
Other All
: Normal normal
: ---
Assigned To: David Zeuthen (not reading bugmail)
gtkdev
Depends on:
Blocks: 741630
 
 
Reported: 2015-02-04 13:43 UTC by Allison Karlitskaya (desrt)
Modified: 2015-02-17 21:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gdbus tests: show a worrying issue (839 bytes, patch)
2015-02-04 13:43 UTC, Allison Karlitskaya (desrt)
none Details | Review
tests: check for NULL before g_object_unref() (1.10 KB, patch)
2015-02-04 16:51 UTC, Allison Karlitskaya (desrt)
committed Details | Review
gdbus: delay closing stream after read finish (2.62 KB, patch)
2015-02-17 21:28 UTC, Allison Karlitskaya (desrt)
committed Details | Review

Description Allison Karlitskaya (desrt) 2015-02-04 13:43:37 UTC
This is pretty complicated, but the main thrust is as follows:

 - we call close_async() on the GIOStream while we still have a pending
   read (due to not properly waiting for the read to finish)

 - we have been protected from this thus far by the fact that the
   default implementation of GIOStream's close() function has been to do
   a sync close() from a thread, which ignores the pending operation

 - we are calling close() on a fd for which we are still polling for
   readability, which is undefined

 - the work in bug 741630 means that we will be doing a proper async
   close, which will (properly) fail because of the pending operation

 - we can see that our testcases are very confused about all of this
   (see attached patch)
Comment 1 Allison Karlitskaya (desrt) 2015-02-04 13:43:39 UTC
Created attachment 296100 [details] [review]
gdbus tests: show a worrying issue

GDBus connection closing isn't working like we think it is.  Observe a
bunch of dead code in one of our testcases...
Comment 2 Allison Karlitskaya (desrt) 2015-02-04 16:46:13 UTC
Applying the patches in bug 741630 will cause the assert to be hit in the patch above.  Removing the assert will then cause the g_object_unref() of the cancellable to fail on NULL cancellable (missed because this dead code was never actually run before).

Fixing that will get give you a good demonstration of the core of the problem: the close_async() in the worker will catch an "operation pending" error.
Comment 3 Allison Karlitskaya (desrt) 2015-02-04 16:51:49 UTC
Created attachment 296139 [details] [review]
tests: check for NULL before g_object_unref()

delayed_close_free() calls g_object_unref() on a variable that is
expected to possibly contain NULL (as indicated by the fact that the
NULL case is handled in my_slow_close_output_stream_close_async()).

This is dead code right now (due to a bug in GDBus), which is why it
isn't actually causing a failure.  It should still be fixed, however.
Comment 4 Allison Karlitskaya (desrt) 2015-02-17 21:28:51 UTC
Created attachment 297063 [details] [review]
gdbus: delay closing stream after read finish

Closing the stream on the writing side my race with a pending read. This
patch ensures that closing is delayed after reading is finished.
Comment 5 Allison Karlitskaya (desrt) 2015-02-17 21:32:18 UTC
Attachment 296139 [details] pushed as c7f0ea4 - tests: check for NULL before g_object_unref()
Attachment 297063 [details] pushed as 512e9b3 - gdbus: delay closing stream after read finish

Thanks Marc-André!