We are using a custom library built buy another team and using it in our application built using c++11.
Since a recent upgrade in our library we are facing
Program received signal SIGSEGV, Segmentation fault.
0x00007efc338f2ce2 in std::__detail::_Prime_rehash_policy::_M_need_rehash(unsigned long, unsigned long, unsigned long) const ()
from /path/share/custom_lib.so
During gdb I found the below error
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fc6b9ffb700 (LWP 196163)]
0x00007fc6d1364e82 in std::__detail::_Prime_rehash_policy::_M_need_rehash (this=0xb, __n_bkt=0, __n_elt=1, __n_ins=10903680147728276093)
at /usr/include/c++/4.4.7/tr1_impl/hashtable_policy.h:492
492 /usr/include/c++/4.4.7/tr1_impl/hashtable_policy.h: No such file or directory.
When I checked our dev machine we have /usr/include/c++/4.8.2/
and the custom_lib.so dev system has /usr/include/c++/4.4.7/.
I understood that it was a compatibility issue with the compilers. But we cant go back to 4.4.7 because using Map instead of unordered_map will cause performace issues. The custom_lib team can't upgrade their compiler.
Thanks
Looking for a hack or work around to fix this issue.
I got the fix for this. It's basically because the dependent lib used a different compiler version. I used std::tr1::unordered_map and it solved the issue
Related
I am trying to suppress ASAN issues in an external library, therefore I am following llvm-asan-suppressing-reports-in-external-libraries, the docs says:
If you run into an issue in external libraries, we recommend immediately reporting it to the library maintainer so that it gets addressed
Blockquote
Update: Here the link to the issue, Issue 45842: AddressSanitizer: bad-free - hello world c extension - Python tracker
ASAN trace
==6968==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x01e7aceb3be0 in thread T0
#0 0x7ffec9a97f31 (D:\a\min_reprex_python_c_extension_asan\min_reprex_python_c_extension_asan\llvm\lib\clang\13.0.0\lib\windows\clang_rt.asan_dynamic-x86_64.dll+0x180037f31)
#1 0x7ffeca696030 (C:\hostedtoolcache\windows\Python\3.10.0\x64\python310.dll+0x180026030)
#2 0x7ffeca67aaaf (C:\hostedtoolcache\windows\Python\3.10.0\x64\python310.dll+0x18000aaaf)
...
#114 0x7ff72208122f (C:\hostedtoolcache\windows\Python\3.10.0\x64\python.exe+0x14000122f)
#115 0x7ffefee17973 (C:\Windows\System32\KERNEL32.DLL+0x180017973)
#116 0x7fff0071a2f0 (C:\Windows\SYSTEM32\ntdll.dll+0x18005a2f0)
Address 0x01e7aceb3be0 is a wild pointer inside of access range of size 0x000000000001.
SUMMARY: AddressSanitizer: bad-free (D:\a\min_reprex_python_c_extension_asan\min_reprex_python_c_extension_asan\llvm\lib\clang\13.0.0\lib\windows\clang_rt.asan_dynamic-x86_64.dll+0x180037f31)
==6968==ABORTING
Here a link to the full ASAN trace.
What I did so far
I created a my_asan.supp and loaded it with ASAN_OPTIONS=suppressions=my_asan.suppas suggested in the docs with the following contents:
interceptor_via_fun:_PyObject_Realloc
interceptor_via_fun:realloc
interceptor_via_lib:C:/Python39/python3.dll
interceptor_via_lib:C:/s/eklang/DevOps/clang/bin/LLVM-13.0.0-win64/lib/clang/13.0.0/lib/windows/clang_rt.asan_dynamic-x86_64.dll
interceptor_via_lib:C:/Windows/System32/KERNEL32.DLL
interceptor_via_lib:C:/Windows/SYSTEM32/ntdll.dll
interceptor_via_lib:C:\Python39\python3.dll
interceptor_via_lib:C:\s\eklang\DevOps\clang\bin\LLVM-13.0.0-win64\lib\clang\13.0.0\lib\windows\clang_rt.asan_dynamic-x86_64.dll
interceptor_via_lib:C:\Windows\System32\KERNEL32.DLL
interceptor_via_lib:C:\Windows\SYSTEM32\ntdll.dll
interceptor_via_lib:clang_rt.asan_dynamic-x86_64.dll
interceptor_via_lib:ntdll
interceptor_via_lib:ntdll.dll
interceptor_via_lib:python3
interceptor_via_lib:python3.dll
interceptor_via_lib:KERNEL32
interceptor_via_lib:KERNEL32.dll
None of these seemed to work, what am I doing wrong? I tried full-path, forward-slash, backslash, dll names ...
Info
LLVM 13, Windows 10
When an executable which was not compiled with asan (in this case python.exe) loads a dll which was compiled with i.
One needs to make sure asan runtime is loaded first for it to do it's magic and properly intercept malloc and free, under linux that's easy, one would use LD_PRELOAD (there are many examples in the internet on how to do that).
In windows though, that seems not possible, therefore a workarounds seems to be to make an executable wrapper with clang_rt.asan-preinit-x86_64.lib and clang_rt.asan-x86_64.lib linked and call python from there, which later on will load the dll needs to be compiled with clang_rt.asan_dll_thunk-x86_64.lib.
The whole things sounds quite convoluted but seems to work so far. This article 👀 helped me.
"dos: Memory allocation error" occurs while loading 'mingw-0.9.3-0' on Scilab 5.5.2.
How can I get rid of these messages?
ATOMS (Scilab's Module Manager) prompted me to install MinGW because some Scilab demos are available only when gcc is installed.
My Machine is 64-bit Windows10 and my Scilab is also a 64-bit version, so I chose a 64-bit version of MinGW.
After that, I installed the interface between them through ATOMS, and restarted Scilab. Then, I got this message:
Startup execution:
loading initial environment
Mingw Compiler support for Scilab
Load macros
Warning !!!
Scilab has found a critical error (EXCEPTION_ACCESS_VIOLATION)
with "stacksize" function.
Save your data and restart Scilab.
Converting Libraries.
Build libblasplus.a
atomsLoad: An error occurred while loading 'mingw-0.9.3-0':
dos: Memory allocation error.
... I searched a solution and all I found is this thread:
https://atoms.scilab.org/toolboxes/mingw
Although their error messages (Undefined operation) are different from mine (Memory allocation error), this seems to be a bug which has not been fixed yet. Incidentally, I already started Scilab with "Run as Administrator" option and no luck. Is there any solution?
I'm also fighting with this problem for a while. Seems to be a incompatibility of the stacksize function on win10 machines.
This fix is working for me:
Find the mingw.start file, it is probably in the directory "scilab-5.5.2\contrib\mingw\0.9.3-0\etc".
Comment out the row #49 with the stacksize('max') order by placing "//" in front of the row
Start scilab, at the first run scilab builds up some libs with mingw so it needs more time than usual
There is unix-socket server written on PHP (but I don't think it has something to with it). Client side is written on c++ and based on boost::asio library. When I launch program normally - everything works fine, except one (not related to socket communication) bug that I obviously want to debug. But when I start step-by-step debugging it I immediately receive 'Broken Pipe' error on the steps which perform write operations on sockets. If breakpoint is set up after socket write operation - everything work fine until the next attempt to step over the write func.
Spent whole day trying to solve this problem, but unsuccessfully...
Had anyone met the same trouble?
using GDB bundled with xCode 3.2.5 (64-bit) under OS X 10.6.7
GDB uses signals aggressively. If you want to install signal handlers, check out the following example:
https://github.com/sean-/Boost.Examples/blob/master/asio/timer/timer.cc#L106
I wrote a small app using the Boost asio example(3) of the multi-threaded HTTP server. Periodically I get a seg fault which occurs if I ctrl-c the app. I know I must be overwriting memory somewhere, but not really sure how to debug it. The stack trace in GDB is not helpful. Are there some tools in GCC that can help me detect the corruption prior to me hitting it in the dtor? (sorry, I am a Java guy mostly)
Thanks. Using Boost 1.38 on Debian Linux
PS Here is the stack trace
Program terminated with signal 11, Segmentation fault.
#0 0xb7f74389 in tls_destructor (data=0xb5200fc8) at libs/thread/src/pthread/thread.cpp:86
86 thread_info->tss_data=current_node->next;
(gdb) where
#0 0xb7f74389 in tls_destructor (data=0xb5200fc8) at libs/thread/src/pthread/thread.cpp:86
#1 0xb7f75351 in thread_proxy (param=0xb5200fc8) at libs/thread/src/pthread/thread.cpp:142
#2 0xb7c03240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#3 0xb7dc049e in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb)
Since this is a multithreaded program, there is a possibility that Boost upgrade only hid a real bug. I`d suggest having a test run using Valgrind Memcheck and Helgrind tools, in that order. The first one checks for memory-management problems, the second one for race conditions. IMHO a truly indispensable tool.
I have an executable built in Windows. I want to pass that .exe to an output file built by Cygwin (DOS version). It is going well up to a point, after which it is showing the following error related to Cygwin dll files (ACL check) .
Program received signal SIGSEGV, Segmentation fault.
0x6108829e in cygwin1!aclcheck () from /usr/bin/cygwin1.dll
(gdb)
Why am I getting this error and where should I look?
Check your code. Since you're already using gdb, bt full shall be your friend. You're possibly passing bad parameters such as invalid pointers to some system call.
It's likely it's not aclcheck where the segfault itself occurs. Cygwin DLLs are normally not shipped with debugging symbols built in. gdb works backwards from the instruction pointer and takes the previous symbol seen. In non-debug builds there are only symbols of exported functions.