Re: [Boost-bugs] [Boost C++ Libraries] #9083: thread_group::join_all() hangs when invoked on dll unload

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #9083: thread_group::join_all() hangs when invoked on dll unload
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2013-09-30 14:40:19

#9083: thread_group::join_all() hangs when invoked on dll unload
-------------------------+-------------------------------------------------
  Reporter:              |      Owner:  viboes
  danobrega@…            |     Status:  closed
      Type:  Bugs        |  Component:  thread
 Milestone:  To Be       |   Severity:  Problem
  Determined             |   Keywords:  thread_group join_all hang deadlock
   Version:  Boost       |  freelibrary windows
  1.54.0                 |
Resolution:  duplicate   |
-------------------------+-------------------------------------------------

Comment (by danobrega@…):

 Hi again,

 Thanks for the pointers hvemha.

 Here's the thing. We don't have a way (or we can't find a way) to properly
 clean up boost on unload. I've attached a new sample application where we
 can see this. And forget about _DllMain, I tried to use it while
 investigating this problem. However the original code had a global
 application object whose destructor was invoked when the dll was being
 unloaded.

 As we can see in the new application if we don't wait for all threads to
 complete and let the "main" thread complete before them, the application
 may crash. I must join with all threads to prevent this from happening.
 (comment define CUSTOM_JOIN_ALL and run the application). This seem to be
 the bug #3926 as specified by the duplicate action on this bug(?).

 On the other hand I can't join with other threads or the application will
 hang (uncomment join_all)

 We've coded a workaround that seems to work (leave define CUSTOM_JOIN_ALL
 uncommented and run the application). In theory this workaround isn't
 enough to guarantee the application does not crash.

 The application can still crash if a thread is preempted just after
 decreasing the live thread counter but before finishing whatever it has to
 do (uncomment define CUSTOM_JOIN_ALL_CAN_STILL_CRASH, run the application
 and wait 10 seconds).

 Also but unrelated we've discovered that calling error_code.message on a
 terminating thread hangs the application. The thread blocks on the system
 call to _FormatMessage. This is an awkward problem as any thread may be
 running code that will try to print an error message. (uncomment
 ERROR_CODE_MESSAGE_HANGS_APPLICATION and run the application).

 On our application the async socket reads handler would be invoked with
 error_code WSA_OPERATION_ABORTED. Since we tried to print the error
 message and since this would typically be the first WSA_OPERATION_ABORTED,
 the thread would hang.

 Apparently however, if we previously called _FormatMessage for that
 particular error code then the application will not hang and
 _FormatMessage returns a properly formated message. (uncomment
 ERROR_CODE_MESSAGE_HANGS_APPLICATION_FIX and run the application).

 We've attached the solution with all problems and workarounds
 (_BoostCleanUpStudy.zip). If anyone knows of a better solution to any of
 the problems please advise.

 Best regards,
 João Graça da Nóbrega

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/9083#comment:11>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.