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.
Related
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'm debugging a shared library. I found that the bug can be trigger when I enable ASLR in Linux host, while the bug disappears when ASLR is disabled.
I want to further debug the shared library with gdb. But I found it always loaded the shared library at a fixed address, which made the bug disappear.
Is there any way to disable this gdb's feature?
Is there any way to disable this gdb's feature?
Yes, you can set disable-randomization off before running the program.
See this part of gdb documentation:
set disable-randomization off
Leave the behavior of the started executable unchanged. Some bugs rear their ugly heads only when the program is loaded at certain
addresses. If your bug disappears when you run the program under GDB,
that might be because GDB by default disables the address
randomization on platforms, such as GNU/Linux, which do that for
stand-alone programs. Use set disable-randomization off to try to
reproduce such elusive bugs.
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?
c++ program terminated with no exceptions or stacktrace
I have a multi threaded application
If one of my threads has an access violation with reading out of bounds on an array (or any seg fault condition) my entire application immediately terminates.
If this happens on my windows counter part using visual studio I get a nice stacktrace of where the error was, and what the issue was.
I desperately need this type of debugging environment to be able to succeed at my project. I have too many threads and too many developers running different parts of the project to have one person not handle an exception properly and it destroys the entire project.
I am running Fedora Core 14
I am compiling with gcc 4.5.1
gdb is fedora 7.2-16.fc14
My IDE is eclipse Juno I am using the CDT builder
my toolchain is the cross GCC and my builder is the CDT Internal Builder
Is there ANY setting for the gdb or gcc or eclipse that will help me detect these type of situations?
That's what's supposed to happen. Under Unix, you get a full
core dump (which you can examine in the debugger), provided
you've authorized them. (ulimits -c—traditionally, they
were authorized by default, but Linux seems to have changed
this.)
Of course, to get any useful information from the core dump,
you'll need to have compiled the code with symbol information,
and not stripped it later. (On the other hand, you can copy the
core dump from your users machine onto your development machine,
and see what happened there.)
You're definitely looking for core dumps, as James Kanze wrote.
I would just add that core dumps will show you where the program crashed, which is not necessarily the same place as where the problem (memory corruption etc.) occurred. And of course some out-of-bounds reads/writes may not exhibit themselves by crashing immediately.
You can narrow the search by enabling check for incorrect memory allocations/deallocations in glibc. The simplest way is to set environmental variable MALLOC_CHECK_. Set it to 2 and glibc will check for heap corruption with every memory allocation/deallocation and abort the program when it founds any problem (producing a core dump, if enabled). This often helps to get closer to the real problem.
http://www.gnu.org/software/libc/manual/html_node/Heap-Consistency-Checking.html
Does anyone know a good debugger for C++ segmentation errors on the Linux environment? It would be good enough if the debugger could trace which function is causing the error.
Also consider some techniques that do require from you code changes:
Run your app via valgrind memcheck tool. It's possible to catch error when you access wrong address (e.g. freed pointer, not initialized) - see here.
If you use extensievly stl/boost, consider compiling with -D_GLIBCXX_DEBUG and -D_GLIBCXX_DEBUG_PEDANTIC (see here). This can catch such errors as using invalidated iterator, accessing incorrect index in vector etc.
tcmalloc (from google per tool). When linking with it's debug enabled version, it may find memory related problems
Even more ...
GDB! what else is available on Linux?
Check this out for starting up with GDB, its a nice, concise and easy to understand tutorial.
GDB is indeed about the only choice. There are some GUI's but they are allmost all wrappers for gdb. Finding a segfault is easy. Make sure you compile with -g -O0 then start gdb with your program as argument.
In gdb type run
To start your program running, gdb will stop it is soon as it hits a segfault and report on which line that was. If you need a full backtrace then just type bt. To get out of gdb enter quit.
BTW gdb has a build in help, just type help.