Boost logo

Boost Users :

Subject: Re: [Boost-users] [asio] still weird crashes with asio using libpion on windows
From: FantasyDR (fantasydr.gg_at_[hidden])
Date: 2009-03-02 20:48:47

I met the same issue. And finally I found it was caused by the sequence of
object destruction.
The asio needs an io_service object to handle all async call.
The io_service implementation such as win_iocp_io_service hold a list of its
service instance.
These instances may be held by object such as tcp::acceptor from their

If io_service was destroyed before the tcp::acceptor then the instance
pointer will be released and cause a crash in tcp::acceptor's destructor.
The solution is very simple: make sure the io_service was destroyed after
all other object that may hold a reference to it.

I hope I've described it clearly and can give you some help :-)

Bugzilla from wrote:
> Hi all,
> I have been experiencing problems with weird crashes on Windows using
> libpion ( and the
> problem is still there with pion 1.0.10 but it changed a little and might
> shed some new light on the
> Let me just outline the situation. I have a simple project with an app and
> two libs, both using boost 1.36 at this time. The app links against those
> two libs, and one of the libs links against pion. So does the app of
> course. I've built pion as debug dll with boost 1.36. This runs on Windows
> and Linux.
> Now on Linux everything is fine, no problem at all, no dangerous valgrind
> output, nothing.
> On Windows however, the application crashes as soon as I do something with
> pion, and the callstack leads me to believe it's got something to do with
> boost asio.
> Usually it happens within asio win_mutex and looks a lot like this:
> To me this looks like an uninitialized mutex is being used.
> Not entirely however. I get this:
> First-chance exception at 0x7c91100b in myapp.exe: 0xC0000005: Access
> violation reading location 0x00000028.
> it's in win_mutex.hpp
> int do_lock()
> {
> #if defined(__MINGW32__)
> // Not sure if MinGW supports structured exception handling, so for
> now
> // we'll just call the Windows API and hope.
> ::EnterCriticalSection(&crit_section_);
> return 0;
> #else
> __try
> {
> -> ::EnterCriticalSection(&crit_section_); // CRASH
> }
> __except(GetExceptionCode() == STATUS_INVALID_HANDLE
> || GetExceptionCode() == STATUS_NO_MEMORY
> {
> if (GetExceptionCode() == STATUS_NO_MEMORY)
> }
> return 0;
> #endif
> }
> This exception repeats many times until eventually the app crashes because
> 'this' is invalid, pointing somewhere it shouldn't.
> The Bug occurs several seconds after the application has started, but I
> don't have to actually access pion's http socket for that. I think it
> might not be pion's fault at all.
> The whole thing only happens on Windows and renders both pion useless on
> that system. I know, it's only Windows but I've been debugging around that
> for some months now and I'd really like that solved at some point.
> Any ideas?
> Thanks a lot...
> Stephan
> PS:
> I can't go to boost 1.37 because of:
> With Chris apparently not responding or posting about ASIO any more is
> there any chance of this being fixed in the next release? Is ASIO
> maintained at all? Cause nobody seems to care about that bug. Again, I
> know it's only Windows but as long as Windows is officially a supported
> system an imporant lib like ASIO should work on it.
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]

View this message in context:
Sent from the Boost - Users mailing list archive at

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at