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 723467 - souphttpsrc: Failing/racy checks
souphttpsrc: Failing/racy checks
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-02-02 10:39 UTC by Edward Hervey
Modified: 2016-04-18 10:54 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Edward Hervey 2014-02-02 10:39:16 UTC
71%: Checks: 14, Failures: 0, Errors: 4
elements/souphttpsrc.c:124:E:general:test_redirect_yes:0: (after this point) Test timeout expired
elements/souphttpsrc.c:124:E:general:test_redirect_no:0: (after this point) Test timeout expired
elements/souphttpsrc.c:124:E:general:test_not_found:0: (after this point) Test timeout expired
elements/souphttpsrc.c:124:E:general:test_forbidden:0: (after this point) Test timeout expired

This is on a slow-ish machine (can't reproduce it on fast machine).

What's "interesting" is that it's constantly those tests that fail (and not the other tests that also use a local web server). I haven't managed to figure out anything that particuliar between those tests and other tests.
Comment 1 Thiago Sousa Santos 2014-03-01 05:01:12 UTC
I have a different set of failing tests here. I added a 1 sec sleep at the end of run_server and now they all work forever.
Comment 2 Tim-Philipp Müller 2016-04-18 10:54:01 UTC
The only racy thing which I've seen or am aware of is an issue I fixed a while back:

commit 8e2c1d1de56bddbff22170f8b17473882e0e63f9
Author: Tim-Philipp Müller <tim@centricular.com>
Date:   Thu Feb 18 13:43:07 2016 +0000

    tests: fix spurious souphttpsrc test timouts
    
    Set GSETTINGS_BACKEND=memory, apparently there's something
    about fork() and the dconf backend (or whatever else that
    drags in or activates) that messes up locking and causes
    timeouts due to deadlocks in g_mutex_lock(), since
    everything works fine with CK_FORK=no as well.

So I'd say let's close this.

Please re-open if you still get other issues.