Mir client library thread safety

Thomi Richards thomi.richards at canonical.com
Mon May 27 05:59:39 UTC 2013

Hey everyone,

I've run into another issue while stress testing mir. The stress test tool
I'm writing currently lives here:


With the mir_demo_server running I can run the stress test with a single
thread just fine:

./mir-stress -t 1 -n 10

But as soon as I try and run with multiple threads:

./mir-stress -t 2 -n 10

roughly 50% of the calls to mir_connect_sync fail, with one of the
following error messages:

"connect: Too many open files"
"eventfd_select_interrupter: Too many open files"

The stress test never opens more connections than it has threads running
(in the above example, two simultaneous connections), so I'm pretty sure
this error state is in fact a bug. I've tried several things to narrow down
the problem, so far without much luck. I'm not even sure if this is en
error state on the client side, or the client api is simply reporting an
error message from the mir_demo_server.

I have tried:

 * Using "strace -e trace=open,close mir_demo_server" and "strace -e
trace=open,close ./mir-stress -t 2 -n 10". The trace log from the demo
server doesn't show any open() calls while the client is trying to connect,
and the client trace log shows balanced open()/close() calls.

 * Running the server and client under valgrind. Valgrind finds a few leaks
on the server side, which all seem to be innocuous (memory leaks, that is,
not file handle leaks), and no leaks in mir-stress.

* Inspecting the output of lsof for both the mir_demo_server and mir-stress
while the stress test is running. The server output looks pretty sane, but
I notice that the mir-stress application has /dev/dri/card0 open a total of
1018 times - which, plus a few more file handles, approaches 1024, which
may be the default limit for the number of open file handles in a single
process... maybe? I'm not sure why these wouldn't show up in my
valgrind/strace adventures earlier however.

Is someone else here able to replicate my results? Has anyone got any ideas
how I can move forwards from here?


Thomi Richards
thomi.richards at canonical.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20130527/b3c1bb76/attachment.html>

More information about the Mir-devel mailing list