https://svn.boost.org/trac10/ticket/6425 <p> prg_exec_fail2.exe runs away, hogging the CPU. This is part of boost's regression test. </p> <p> It happens only under MinGW-64, gcc-4.4. (gcc 4.5, 4.6, 4.7 all work). This is likely a problem with the MinGW-64 library, but reported here as it affects boost.test. </p> <p> Connecting to the runaway-process with gdb, here's what I see. </p> <p> Trunk regression test... </p> <pre class="wiki">Reading symbols from G:\boost\GCC\trunk\results\boost\bin.v2\libs\test\test\prg_ exec_fail2.test\gcc-mingw-4.4.7\debug\prg_exec_fail2.exe...done. [Switching to Thread 2044.0x13b4] (gdb) bt #0 0x00000000772c0531 in ntdll!DbgUiContinue () from C:\Windows\SYSTEM32\ntdll.dll #1 0x0000000077367ef8 in ntdll!EtwEventActivityIdControl () from C:\Windows\SYSTEM32\ntdll.dll #2 0x0000000000000000 in ?? () (gdb) info thread Id Target Id Frame * 2 Thread 2044.0x13b4 0x00000000772c0531 in ntdll!DbgUiContinue () from C:\Windows\SYSTEM32\ntdll.dll 1 Thread 2044.0x1488 0x0000000000401700 in cpp_main () at ..\libs\test\test\prg_exec_fail2.cpp:37 (gdb) thread 1 [Switching to thread 1 (Thread 2044.0x1488)] #0 0x0000000000401700 in cpp_main () at ..\libs\test\test\prg_exec_fail2.cpp:37 37 return 10 / div; (gdb) bt #0 0x0000000000401700 in cpp_main () at ..\libs\test\test\prg_exec_fail2.cpp:37 #1 0x000000000040176f in (anonymous namespace)::cpp_main_caller::operator() ( this=0x22fd08) at ../boost/test/impl/cpp_main.ipp:49 #2 0x0000000000401f91 in boost::detail::function::function_obj_invoker0&lt;&lt;unname d&gt;::cpp_main_caller, int&gt;::invoke(boost::detail::function::function_buffer &amp;) (function_obj_ptr=...) at ../boost/function/function_template.hpp:132 #3 0x00000000004192ac in boost::function0&lt;int&gt;::operator() (this=0x22fd00) at ../boost/function/function_template.hpp:760 #4 0x0000000000414d8a in boost::detail::do_invoke&lt;boost::detail::translator_hol der_base_ptr, boost::function&lt;int()&gt; &gt;(const boost::detail::translator_holder_ba se_ptr &amp;, const boost::function&lt;int()&gt; &amp;) (tr=..., F=...) at ../boost/test/impl/execution_monitor.ipp:256 #5 0x00000000004025e2 in boost::execution_monitor::catch_signals(const boost::f unction&lt;int()&gt; &amp;) (this=0x22fcb0, F=...) at ../boost/test/impl/execution_monitor.ipp:1152 #6 0x000000000040282d in boost::execution_monitor::execute(const boost::functio n&lt;int()&gt; &amp;) (this=0x22fcb0, F=...) at ../boost/test/impl/execution_monitor.ipp:1183 #7 0x000000000040191b in boost::prg_exec_monitor_main ( cpp_main=0x4016e0 &lt;cpp_main(int, char**)&gt;, argc=1, argv=0x88ff90) at ../boost/test/impl/cpp_main.ipp:77 #8 0x0000000000401e10 in main (argc=1, argv=0x88ff90) at ../boost/test/impl/cpp_main.ipp:127 </pre><p> And the release-branch regression test... </p> <pre class="wiki">Attaching to process 6024 [New Thread 6024.0x1218] [New Thread 6024.0xba4] Reading symbols from G:\boost\GCC\release\results\boost\bin.v2\libs\test\test\pr g_exec_fail2.test\gcc-mingw-4.4.7\debug\prg_exec_fail2.exe...done. [Switching to Thread 6024.0xba4] (gdb) bt #0 0x00000000772c0531 in ntdll!DbgUiContinue () from C:\Windows\SYSTEM32\ntdll.dll #1 0x0000000077367ef8 in ntdll!EtwEventActivityIdControl () from C:\Windows\SYSTEM32\ntdll.dll #2 0x0000000000000000 in ?? () (gdb) info threads Id Target Id Frame * 2 Thread 6024.0xba4 0x00000000772c0531 in ntdll!DbgUiContinue () from C:\Windows\SYSTEM32\ntdll.dll 1 Thread 6024.0x1218 0x000007fefde1167c in signal () from C:\Windows\system32\msvcrt.dll (gdb) thread 1 [Switching to thread 1 (Thread 6024.0x1218)] #0 0x000007fefde1167c in signal () from C:\Windows\system32\msvcrt.dll (gdb) bt #0 0x000007fefde1167c in signal () from C:\Windows\system32\msvcrt.dll #1 0x000000000040925a in __mingw_SEH_error_handler ( ExceptionRecord=&lt;optimized out&gt;, EstablisherFrame=&lt;optimized out&gt;, ContextRecord=0x22ef40, DispatcherContext=0x22e8f0) at ../mingw-w64-crt/crt/crt_handler.c:154 #2 0x0000000077299d0d in ntdll!RtlDeleteBarrier () from C:\Windows\SYSTEM32\ntdll.dll #3 0x0000000000401700 in cpp_main () at ..\libs\test\test\prg_exec_fail2.cpp:37 #4 0x000000000022f750 in ?? () #5 0x000000000022f6b0 in ?? () #6 0x000000000040176f in (anonymous namespace)::cpp_main_caller::operator() ( this=0x0) at ../boost/test/impl/cpp_main.ipp:49 #7 0x0000000000050008 in ?? () #8 0x0000000000000000 in ?? () (gdb) </pre> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/6425 Trac 1.4.3 Jim Bell <jim@…> Fri, 20 Jan 2012 15:59:56 GMT https://svn.boost.org/trac10/ticket/6425#comment:1 https://svn.boost.org/trac10/ticket/6425#comment:1 <ul> <li><strong>summary</strong> <span class="trac-field-old">Regression test: prg_exec_fail2 process runs away, mgw64 gcc4.4</span> → <span class="trac-field-new">Regression test: prg_exec_fail2 process runs away, mgw64 gcc 4.4, 4.5</span> </li> </ul> <p> Update: this same problem occurs with MinGW-64 gcc 4.5. Both trunk and release test programs seem to remain compute-bound indefinitely (i.e., hog a CPU). Both, when attached with gdb, show a stack-trace just like the above trunk trace. </p> <p> Note also that the regression test has moved on and didn't kill this task as it should have. (Is that the crux of the issue?) </p> Ticket Gennadiy Rozental Wed, 08 Jul 2015 04:54:53 GMT https://svn.boost.org/trac10/ticket/6425#comment:2 https://svn.boost.org/trac10/ticket/6425#comment:2 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">wontfix</span> </li> <li><strong>milestone</strong> <span class="trac-field-old">To Be Determined</span> → <span class="trac-field-new">Boost 1.59.0</span> </li> </ul> <p> I am not sure if we can do anything about this. If you have specific patch in mind please submit. Otherwise this is either compiler or platform or build system issue </p> Ticket