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 719727 - glib-networking/connection.test /tls/connection/close-during-handshake busy loop
glib-networking/connection.test /tls/connection/close-during-handshake busy loop
Status: RESOLVED DUPLICATE of bug 722336
Product: glib
Classification: Platform
Component: network
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2013-12-02 22:32 UTC by Colin Walters
Modified: 2014-01-20 17:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
backtrace (24.43 KB, text/plain)
2013-12-02 22:32 UTC, Colin Walters
  Details
trace (6.17 KB, text/plain)
2013-12-02 22:33 UTC, Colin Walters
  Details
tls/tests/connection: don't spin waiting for shutdown to complete (3.99 KB, patch)
2013-12-08 08:58 UTC, Dan Winship
committed Details | Review

Description Colin Walters 2013-12-02 22:32:09 UTC
Created attachment 263347 [details]
backtrace

This test appears to have several issues.  First, I sometimes get a busy loop in at least the /tls/connection/close-during-handshake test, with the following trace:
Comment 1 Colin Walters 2013-12-02 22:33:46 UTC
Created attachment 263348 [details]
trace

Blah, keep forgetting gdb's "set logging on" appends.
Comment 2 Dan Winship 2013-12-03 15:41:18 UTC
The busy-wait means the test has failed. (It's waiting for another thread to do the final unref on an object; if it gets stuck looping that means something is unexpectedly holding an extra ref on the object). I guess I should add a timeout and make it fail properly.
Comment 3 Dan Winship 2013-12-08 08:58:34 UTC
Created attachment 263731 [details] [review]
tls/tests/connection: don't spin waiting for shutdown to complete

Rather than spinning forever waiting for variables to be unreffed by
other threads, sleep for increasingly-long intervals until about 10
seconds pass, and then abort if the variable is still set.

Addresses the current symptoms of
https://bugzilla.gnome.org/show_bug.cgi?id=719727, but not the
underlying leak that appears to be happening in some cases.
Comment 4 Colin Walters 2013-12-08 14:53:57 UTC
Review of attachment 263731 [details] [review]:

OK; as long as we expect this to happen "reasonably quickly", the 10s timeout should be fine.  But it is another potential source of race conditions as the VM running tests gets fully loaded.
Comment 5 Dan Winship 2013-12-08 16:27:41 UTC
Pushed. Leaving this bug open since it's presumably going to switch to "connection.test fails sporadically sometimes" now
Comment 6 Dan Winship 2014-01-20 17:17:47 UTC
figured out why it was failing, and fixed it

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