https://svn.boost.org/trac10/ticket/12474 <p> Dear developer (or developers) of Boost Asio,<br /> <br /> I think I've found a bug in Asio. If I instantiate two different TCP resolvers on the same io_service and I use these two distinct resolvers for resolving the same endpoint, a race condition is generated.<br /> <br /> I have attached two sources (C++11 is required) that reproduce the issue. Unfortunately you need to run the programs many times to experience a failure ... I have bash scripts that allow me to run these programs thousands of times, each time using a different, random, free port on the local host.<br /> <br /> Quick instructions for running the tests:<br /> <br /> <code>test_engine_client_dbg_x -s -p &lt;port&gt;</code><br /> <br /> runs the server.<br /> <br /> <code>test_engine_client_dbg_x -c -p &lt;port&gt;</code><br /> <br /> Runs the client.<br /> <br /> <code>test_engine_client_dbg_2.cpp</code> is the source that fails (at line 364) because, with no apparent reason, we find (sometimes) the pointer to <code>mEngineClient</code> to be <code>NULL</code>. I've also verified that if in this code I insert a <code>while</code> loop that waits until <code>mEngineClient.get() != nullptr</code>, the code proceeds with no error (meaning that, at some point, that pointer is reset to the correct value). But, I repeat, there is no reason why <code>mEngineClient.get()</code> should be <code>NULL</code> in this point.<br /> <br /> <code>test_engine_client_dbg_4.cpp</code> is the source that works. Notice that this time I'm not instantiating a second resolver within the <code>EngineClient</code> class, but I'm simply passing the already-resolved endpoint iterator to the <code>EngineClient</code>'s constructor. With this change, we never loose the <code>mEngineClient</code> pointer.<br /> <br /> This race condition can be experienced only if we call <code>io_service.run()</code> from multiple threads. I've verified that this does not happen if we call a single <code>io_service.run()</code>.<br /> <br /> Also, I think it is difficult to be reproduced, because I've experienced it only on one specific machine that, maybe, has a different timing with respect to the others I have (because of its hardware). On this machine (which has Fedora 23 OS, with kernel 4.7.3 and gcc 5.3.1) I've also tried re-building by using gcc 4.8.5, but the issue is the same (so this is not a compiler bug). I've also tried, on the same machine, with Fedora 24 OS (yes ... I re-installed the OS) and so I was also able to test with gcc 6.1 and the issue comes out again. On other machines (I've tried also a CentOS6, with 8 cores and gcc 4.8.5) I was not able to reproduce this issue even running the tests thousands of times, while on the Fedora machine where I'm experiencing this issue, it happens basically for sure within 1000 runs.<br /> <br /> In summary, stress test is the only way to hope to experience this bug (but sometimes it also comes out at the first run). </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/12474 Trac 1.4.3 michele.de.stefano@… Wed, 21 Sep 2016 09:48:31 GMT https://svn.boost.org/trac10/ticket/12474 https://svn.boost.org/trac10/ticket/12474 <ul> <li><strong>attachment</strong> → <span class="trac-field-new">test_engine_client_dbg_2.cpp</span> </li> </ul> <p> This is the code that has the race condition </p> Ticket michele.de.stefano@… Wed, 21 Sep 2016 09:49:16 GMT https://svn.boost.org/trac10/ticket/12474 https://svn.boost.org/trac10/ticket/12474 <ul> <li><strong>attachment</strong> → <span class="trac-field-new">test_engine_client_dbg_4.cpp</span> </li> </ul> <p> This is the code that does NOT have the race condition </p> Ticket michele.de.stefano@… Wed, 21 Sep 2016 10:09:14 GMT