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 constructor. 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 stephan.menzel@gmx.eu wrote:
Hi all,
I have been experiencing problems with weird crashes on Windows using libpion (http://www.pion.org/projects/pion-network-library) 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: http://trac.atomiclabs.com/ticket/32 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 ? EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH) { if (GetExceptionCode() == STATUS_NO_MEMORY) return ERROR_OUTOFMEMORY; return ERROR_INVALID_HANDLE; }
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: https://svn.boost.org/trac/boost/ticket/2541 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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- View this message in context: http://www.nabble.com/-asio--still-weird-crashes-with-asio-using-libpion-on-... Sent from the Boost - Users mailing list archive at Nabble.com.