On my MacBook at work, I'm trying to use LLDB to attach to a running Ruby process.
It's normally suggested that one compile Ruby with the debug flag -ggdb(3) to use GDB. But I can't find anything equivalent for LLDB. My Google-fu is failing me, so I thought I'd ask, since this seems like an obscure request.
I would assume that all that -ggdb does is produce debug information. The format for this debug information is most likely DWARF, which both GDB and LLDB understand
If that is the case, -ggdb is a misnomer and should be fixed. But, for your intents and purposes, you should be able to just compile with -ggdb and then attach with LLDB and things should be all right
Related
I have an C-application which runs on many machines and from time to time an instance makes issues and behaves weird. Unfortunately, this happens almost never. These prod-instances are compiled with heavy optimizations (-march=XXX -Ofast) and do not include any debug-symbols, so I cannot easily attach a debugger to analyze their state.
But I thought it should be possible to compile the application again with the same flags plus -g3 and then I can load it in gdb with symbol-file application_executable_with_debug_symbols. However, if I do that then breakpoints never trigger.
Is there another way to attach a debugger to a running application and loading debug-symbols? Or is there something (obvious) which I do wrong?
Thanks
The best practice is to build the application with debug symbols, keep the resulting binary for debugging, but run strip -g app.debug -o app.release and run the stripped binary in production.
When you find a misbehaving instance, you can copy the full-debug version to target machine, and run gdb -ex 'attach $PID' app.debug. Voila: you have full debug symbols.
The most likely reason that compiling the application again didn't work is that you got a new binary with different symbols (compare nm app.debug vs. nm app.release), and the most likely reason for that (if using GCC) is that you omitted some of the optimization flags used to build app.release, or you used slightly different sources -- you must use exactly the same flags (and add -g) and exactly the same sources for any hope of success with that approach.
I'm using Clang to compile my project, on x86_64 OS X(MacOS 10.15.5 Catalina).
I want to identify exactly from which file, which function, which line causes memory leaks. I am trying to use Address Sanitizer, specifically Leak Sanitizer.
Here are flags that I'm using when compiling:
-Wall -Wextra -flto -O3 -march=native -ffast-math -fsanitize=address
It successfully compiles. However, when I try to use run-time flag ASAN_OPTIONS=detect_leaks=1 in order to enable Leak Sanitizer, I see the following error:
==26454==AddressSanitizer: detect_leaks is not supported on this platform.
Abort trap: 6
What am I doing wrong? How could I fix this?
Or, is there another good alternative to a Valgrind? Valgrind doesn't work for me because 1)I'm using the MacOS Catalina, 2)My program runs with an infinite loop. If I'm right, Valgrind displays messages after exiting the program, so it won't work.
I would appreciate it if anyone could give me advice on this issue.
What am I doing wrong?
Nothing. The issue is that your version of Clang does not support leak detection. However, it looks like the latest version does. See this answer and this recipe.
Valgrind displays messages after exiting the program, so it won't work.
You are somewhat correct: by default, Valgrind will perform leak analysis only at program exit.
There are two ways around this:
Make your program exit at some well defined place in the execution, e.g. after performing N calculations, or drawing K frames, etc.
Make your program perform VALGRIND_DO_LEAK_CHECK client request.
If you want to perform the leak check only when certain conditions hold, and it's hard to detect whether these conditions are true from within the program, you could use GDB and the monitor command to ask Valgrind to perform leak check when desired.
I am currently working on WinAPI Gui application under MinGW. In debug version I want to open console and redirect stdin/stdout streams to it, so I can see diagnostic messages being printed in debug. I followed this article:
http://justcheckingonall.wordpress.com/2008/08/29/console-window-win32-app/
It works under Visual Studio, but when compiled on MinGW it spits this message, even if stdio.h is included:
error: '_fdopen' was not declared in this scope
Arguments for MinGW:
mingw32-g++.exe -march=pentium4 -std=c++11 -w -fpermissive -fno-strict-aliasing -D__STDC_CONSTANT_MACROS -D_WINDOWS -DUNICODE -D_UNICODE -g -D_DEBUG
I've googled a lot and it seems to be a bug in MinGW, there is no _fdopen defined in header if C++11 is used. Since I rely on C++11 features, I cannot turn it off, so I am looking for alternatives - is there any way to open console on Windows and redirect stdin/stdout that does not rely on fdopen? If not, are there any other solutions to my problem?
I tried also to manually declare _fdopen (or fdopen), but then it didn't pass the linking phase
MinGW version: 4.7.1
From some brief research, it is my understanding that you should be able to use _fdopen/fdopen in GNU C++11 with the right configuration settings (i.e., by enabling POSIX functions) but that there is a long-standing bug in the Windows implementations. Whether you can directly work around this issue presumably depends on which runtime library you're using.
However, there are various other potential workarounds depending on the scenario:
In your particular case, since you're making the decision at build time, you can simply build the debug version as a console application and let Windows do the work.
It should be possible (again, depending on the runtime library) to configure the build so that some code of yours runs before the runtime library initialization; hopefully, if the console is already present the runtime library will import the standard streams during initialization.
You should be able to open CONIN$ and/or CONOUT$ using fopen so as to obtain FILE objects directly, rather than using GetStdHandle to obtain Windows handles. This is probably the most general solution.
Guys, I have successfully built a debug version of Chromium on OS X Mavericks‎ 10.9.2 by following this instruction with ninja -C out/Debug chrome.
The question is when I debugging(using lldb) into the Chromium, I cannot show all of the variable's value in the debugger:
The variable isolate is showing correct, but not the element_size. How can I let the debugger know where to find the element_size and others? Is this something about global and local variable? Thanks!
Check your optimization settings. If you are not building -O0 it may be that the compiler has figured out it doesn't need this variable, and so the debugger's not going to be able to find it.
(Preface: I'm pretty new to C/C++ and I don't really know how debugging in native code actually works.)
Some sources say that gdb and lldb can debug any program compiled to machine code. Others say that to debug with gdb you must compile in gcc with the -g flag. The documentation for gcc itself suggests this is optional, and that in fact if you use it, it can cause problems for debuggers other than gdb. Clang also has a -g flag and the documentation basically just says "Generate debug information."
So are these debuggers restricted to their own toolchains (GNU and LLVM), or are they somehow independent of the compiler used?
In theory you should be able to debug a GCC-built program with lldb and an LLVM-built program with gdb. In both cases you should compile with -g.
This is because both compilers generate object files in the same format (e.g., on Linux, both will generate ELF files with DWARF debug info) and both debuggers know how to parse that format.
In practice, both compilers push some data into the debug info that only their respective debugger knows how to consume. However:
LLVM-generated data should not hinder gdb in any way.
GCC-generated data should not hinder lldb, but if it does you can specifically ask gcc to not add non-standard data. For example, on Linux, using -gdwarf-2 over -g should only generate standard-compliant DWARF.
Notice that you can also debug programs without debug info (not compiled with -g), but you'll be limited to low-level information in the debugger - assembly code, memory and registers - and will not be able to see high level constructs such as line numbers, function names, mapping between variable names and their content, etc.