I've been attempting to get address sanitizer working in Xcode to find the source of a memory stomping bug. I've changed my standard compiler to the latest trunk version of Clang, and added -fsanitize=address to the compiler and linker flags for the target. However, when building the target, I the the error Ran out of registers during register allocation. When building without the -fsanitize=address flag I get no problems, only when I use that flag does the problem occur.
What could be the cause of this problem? I've got 16GB of RAM available so I don't think the build is running out of memory, and I can't find an explanation of what this error means anywhere. Could this be a bug in the latest Clang?
Related
Minimum reproducible example: https://godbolt.org/z/4hje5h1js
A great feature of ubsan (undefined behavior sanitizer) is to issue a trap that breaks into gdb when an issue occurs. This is turned on with -fsanitize-undefined-trap-on-error. However asan (address sanitizer) does not seem to have such option.
Is that correct or I'm missing the proper documentation? If not, is there anything intrinsic about address sanitizer that prevents it doing a trap?
Compiling with clang 10.0 on Ubuntu 20.04 LTS.
For historical reasons Asan simply exits the application on error but you can ask it to abort (which will be intercepted by gdb) by setting environment variable:
export ASAN_OPTIONS=abort_on_error=1
Or you could simply set a breakpoint at __asan_report_error in gdb.
In one of my C++-projects I found an issue related to a linked library which results in a segfault directly after starting the compiled executable. I tried to dive into the issue using gdb, but it fails with the output:
../../gdb/dwarf2/read.c:1857: internal-error: bool dwarf2_per_objfile::symtab_set_p(const dwarf2_per_cu_data*) const: Assertion `per_cu->index < this->m_symtabs.size ()' failed.
After it is an internal error I am not able to do much (except reporting it), but I still would like to be able to debug the program itself. Which options do I have for that?
Use of a different debugger than gdb?
Manual update to a newer version of gdb (currently on 10.1)?
Somehow catch the segfault before it is damaging the debugger?
?
Most likely this is already fixed gdb bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28160. It has Target Milestone 11.1, so update to a latest version of gdb which is 11.1 now. It should be fixed in that version.
I need to run a rather large software package on a new machine for work. The application is written in C and C++ and I am running on CentOS 6.5.
The program builds fine, but segfaults when I go to run it. Using valgrind, I see the following error reported at the location of the segfault:
==23843== Invalid read of size 4
[stack trace here]
==23843== Address 0x642e7464 is not stack'd, malloc'd or (recently) free'd
So for some reason we are reading from memory we aren't supposed to and are invoking undefined behaviour. When I tar up my source files, take them to another CentOS 6.5 machine (w/ same kernel) and compile them (with same makefiles and same GCC version) the program seems to run fine.
I ran valgrind on that machine as well and expected to see the invalid read again. My thought was that the invalid read would always be present, yet because the behaviour is undefined things just happened to work correctly on one machine and not on the other.
What I found, however, was that valgrind reports no read errors on the second machine. How could this be possible?
Valgrind makes the running environment more deterministic, but it does not eliminate all randomness. Maybe the other machine has bit different versions of libraries installed, or anything external it is using (files, network..) is different, the code execution does not have to be exactly the same.
You should look at the stack trace and analyze the code where the error happens. If it is not obvious from the stack trace alone, you can start valgrind with --vgdb=full parameter. It will pause the execution once the error happens and print out instructions how to attach gdb. Or you can just run the program under debugger directly - you wrote that it crashes even without valgrind.
Different library versions are the best guess, judging from the sparse information you gave. Things to try:
1) Bring both machines up to date via package manager and try again
2) Run ldd [binary] to see all libraries used by the program in question. Run something like md5sum on them on both machines to find out if there are differences.
In general I made the experience that valgrind is really bad at detecting invalid memory access on the stack, so this might be a hidden root cause. If all else fails, you might want to try using clang and address sanitizer. It might find things valgrind doesn't catch, and vice versa.
This could be caused by using different versions of Valgrind.
Some common false positive errors get removed in newer versions. Which would explain why one machine complains about it (older version) and another one doesn't (newer version).
I'm trying to compile one of my games on Windows, but unfortunately, no matter what, I'm getting this segmentation fault every time I run the program.
Compilation is successful, and without any warning.
Program received signal SIGSEGV, Segmentation fault.
__chkstk_ms () at ../../../../../src/gcc-4.8.1/libgcc/config/i386/cygwin.S:172
172 ../../../../../src/gcc-4.8.1/libgcc/config/i386/cygwin.S: No such file or directory.
I've tried:
Compiling on a Windows x86 machine
Compiling on a Windows x64 machine
nuwen.net's MinGW distro
TDM MinGW 4.8.1 SJLJ
MinGW builds x86 SJLJ
MinGW builds x64 SJLJ
MinGW builds x86 DW2
I've built all dependencies from source multiple times, tried linking both statically and dynamically.
Debugging doesn't help either - GDB gives me that error message just upon entering main(). I've used -g3 and -O0 flags.
How can I figure out what's happening?
On Windows, the default stack size is smaller than Linux. __chkstk_ms appears to be a function that crashes if you overflow your stack.
You may try to figure out where in your code you are creating huge stack variables or doing very deep recursion, and fix that.
Alternately, you may be able to add a compile flag to increase the stack size. See http://trac.sagemath.org/ticket/13960.
Try to increase stack size. Don't ask me how, I don't know.
The failing call (__chkstk_ms) looks like internal routine which checks if there is enough stack space for the function about to be executed.
I have (probably quite common) issue that my code crashes with:
unknown location(0): fatal error in "BaumIteration_OneDimensionCase": memory access violation at address: 0xfffffff8: no mapping at fault address
for an optimized build (-O3 in gcc under Linux), but works fine in a debug build. I tried to debug the release build, but it just doesn't give any useful information. What are the standard techniques to solve this issue?
In some other question someone suggested using valgrind. How do I use it in this particular circumstances (if this is the right way forward anyways...)?
As mentioned , there is some code bug , but it so happens that due to different code generated, memory addresses used, it does not show up in unoptimized, debug build.
Since you asked about valgrind, the specific valgrind tool you should use is memcheck. It does a run time analysis of the code. It sure would help to find any possible errors or warnings in heap errors like memory leaks, array overbound access(Read/write), double frees ...
If you are on Linux platform , this is how to run your binary under valgrind:
valgrind --tool=memcheck --leak-check=full --show-reachable=yes --log-file=valgrind-log.txt -v --track-origins=yes <your binary file>
Read more about valgrind memcheck here.
Also if possible and if you use g++ to build , add these compiler options to your build process:
-Wall -Wextra -pedantic -Wuninitialized
Analyze the errors/warnings thrown by g++. It might show possible cause of error.
Goodluck debugging!
It's probably a problem that exists even in the debug build, but due to memory layout and what is being corrupted, it probably doesn't show up. As start point look at all the dynamic allocations, frees, arrays, pointers, uninitialized variable!
If i face this problem I will reduce the code size step by step to see if the problem exists this way I can find the location which is causing problem!
Another option is Intel Inspector which has similar capabilities to Valgrind. It comes with parallel studio and is really good at tracking memory errors down and pointing right to the problems.
If you're working on the cheap that may be no help but we all use the intel compiler where I work so it was a dream to save a bunch of time vs trying to hunt this down otherwise