Bug 36179

Summary: Tests fail with G_IO_ERROR_TOO_MANY_OPEN_FILES
Product: Telepathy Reporter: Will Thompson <will>
Component: gabbleAssignee: Telepathy bugs list <telepathy-bugs>
Status: RESOLVED FIXED QA Contact: Telepathy bugs list <telepathy-bugs>
Severity: normal    
Priority: medium Keywords: patch
Version: unspecified   
Hardware: Other   
OS: All   
URL: http://cgit.collabora.co.uk/git/user/wjt/telepathy-gabble-wjt.git/log/?h=test-failures-due-to-fd-limit
Whiteboard: r+
i915 platform: i915 features:

Description Will Thompson 2011-04-12 12:11:42 UTC 
Somewhere during the Jingle test cases, 'make check' fails with G_IO_ERROR_TOO_MANY_OPEN_FILES. This seems to be solely related to the number of tests which have been run: the attached branch includes a test case which simply connects and disconnects repeatedly, forever, until Gabble fails to connect.

I don't think it's an actual leak, per se: the fact that subsequent tests pass after the unluckily-placed Jingle test times out suggests that allowing Gabble a few seconds to recuperate and release its FDs.

The attached branch also adds a leak fix to gabbletest.py which makes the jingle tests measurably faster: from ~65 seconds to ~60 seconds on average. It should have a similar effect on the bytestream tests, and any other tests which run more than one test case from the same Python program.
Comment 1 Jonny Lamb 2011-04-13 00:29:05 UTC 
I also reviewed your misc branch.

+ g_simple_async_result_set_from_error (result, error);
+ g_clear_error (&error);

You could use take_error if we are depending on new enough GLib? I guess not?

--- a/dev/null
+++ b/tests/twisted/fuck-yeah-sharks.py

I'm not sure about including this tbh. If you do, I'm going to have to drop all my values and ask you to rename it. :-(

Oh I only just noticed you didn't set the patch keyword. Well, surprise review!
Comment 2 Will Thompson 2011-04-13 07:33:52 UTC 
pushed a fix.
Comment 3 Will Thompson 2011-04-13 09:53:13 UTC 
(In reply to comment #1)
> I also reviewed your misc branch.
> 
> + g_simple_async_result_set_from_error (result, error);
> + g_clear_error (&error);
> 
> You could use take_error if we are depending on new enough GLib? I guess not?

I think people complained last time someone did that.

> 
> --- a/dev/null
> +++ b/tests/twisted/fuck-yeah-sharks.py
> 
> I'm not sure about including this tbh. If you do, I'm going to have to drop all
> my values and ask you to rename it. :-(

I renamed it. :(
Comment 4 Jonny Lamb 2011-04-13 12:13:04 UTC 
Looks fine.

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.