Help on anything to try...
I am facing a weird crash using boost asio when the client segfaults upon exit on the Release builds of my program after the server has closed the connection. The crash happens upon exit of the application (so my guess it is probably some static destructor crashing), not at the end of the connection to the server. The crash does not occur on the Debug version of my application, nor does asan report any memory trashing. The crash also does not happen if I don't do any network connections in my application (boost::asio does not run any io_services). The crash also happens on Linux only and not on Windows. I created a relatively smaller client/server program like my executable and there's no crash there either. I have run out of things to try. Can someone suggest something I can try to see where the crash is happening? -- Gonzalo Garramuño
On 6/04/2020 06:15, gga wrote:
I am facing a weird crash using boost asio when the client segfaults upon exit on the Release builds of my program after the server has closed the connection. The crash happens upon exit of the application (so my guess it is probably some static destructor crashing), not at the end of the connection to the server. The crash does not occur on the Debug version of my application, nor does asan report any memory trashing. The crash also does not happen if I don't do any network connections in my application (boost::asio does not run any io_services). The crash also happens on Linux only and not on Windows.
I created a relatively smaller client/server program like my executable and there's no crash there either.
I have run out of things to try. Can someone suggest something I can try to see where the crash is happening?
It's difficult to say anything concrete without an MCVE to look at. But crashes with ASIO are almost always the result of getting the handler lifetime wrong, most commonly: - not waiting for run() threads to actually stop before starting to delete objects - using multiple run() threads without appropriate locking or strands - not keeping buffer objects alive until their handler is called - trying to re-use buffer objects inappropriately in multiple async calls - not using shared_ptr to manage lifetime of operation objects, or using them incorrectly - doing something that causes a double-free of memory Keep trying to make an MCVE. If you can find one that doesn't crash and one that does, then the difference between the two may prove enlightening.
On 5/4/20 19:57, Gavin Lambert via Boost-users wrote:
On 6/04/2020 06:15, gga wrote:
I am facing a weird crash using boost asio when the client segfaults upon exit on the Release builds of my program after the server has closed the connection. I have run out of things to try. Can someone suggest something I can try to see where the crash is happening?
It's difficult to say anything concrete without an MCVE to look at.
I know. Another thing I forgot to mention is that if my client exits before my server does, there's no crash either. Also, if I follow the crash on gdb, the result is: Thread 1 "mrViewer" received signal SIGSEGV, Segmentation fault. __GI_getenv (name=0x7fffebd92f7b "UTLS_NO_EXPLICIT_INIT") at getenv.c:84 84 getenv.c: No existe el archivo o el directorio. I tried using GNUTLS_NO_EXPLICIT_INIT in my environment but the crash happens nevertheless. If I try it with valgrind, it says the invalid read 2 crash happens in gnutls or in some std::locale call. -- Gonzalo Garramuño
On 5/4/20 19:57, Gavin Lambert via Boost-users wrote:
Keep trying to make an MCVE. If you can find one that doesn't crash and one that does, then the difference between the two may prove enlightening.
I was able to not make my program crash by commenting a bunch of lines. Upon further investigation I found out that it was not an asio issue but a putenv() call causing the trouble by not allocating the memory with strdup. Thanks for the support and help provided. -- Gonzalo Garramuño
participants (2)
-
Gavin Lambert
-
gga