Bug 36179 - Tests fail with G_IO_ERROR_TOO_MANY_OPEN_FILES
Summary: Tests fail with G_IO_ERROR_TOO_MANY_OPEN_FILES
Status: RESOLVED FIXED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: gabble (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL: http://cgit.collabora.co.uk/git/user/...
Whiteboard: r+
Keywords: patch
Depends on:
Blocks:
 
Reported: 2011-04-12 12:11 UTC by Will Thompson
Modified: 2011-04-14 04:05 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

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.