|
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
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_at_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_at_[hidden]
> 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-windows-tp21703803p22159223.html Sent from the Boost - Users mailing list archive at Nabble.com.
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net