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.
Related
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.
(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.
I'm studying "Compilers" and we work on Flex to program.
I create *.lex files (with any editor), convert them into lex.yy.c via flex, and then compile to a.exe using gcc.
Writing lex code in an editor like Notepad/Codeblocks/... is not only hard because everything is just BLACK, but also there is no debugging system.
The gcc compiler does tell about errors, but what i'm looking for is something i can go line by line with the code (in runtime) and see what's going on with the variables. Like the command F10 in Visual Studio.
Does anybody know a suitable program for this? Thanks alot
Concerning hightlighting, using gedit(The default GUI editor on Ubuntu and some other Linux variants) or even vim will provide that for you, you don't have to use plain notepad.
As for the debugging, yes there's what's called the GNU Debugger (aka GDB) which allows you to do typical debugging jobs after you've compiled your code, you can step line by line and examine certain variable values.
Before doing that, first compile your program with the gcc flag -g to add debug symbols to the complied result, then run gdb yourProgramName, this will run GDB and you'll be able, using certain commands, to do whatever debugging tasks you want.
I once wrote a little guide to help people get started with GDB, it might be useful.
What is the difference between Start Debugging (F5) and Start without Debugging (CTRL-F5) when the code is compiled in Release mode?
I am seeing that CTRL-F5 is 10x faster than F5 for some C++ code. If I am not wrong, the debugger is attached to the executing process for F5 and it is not for CTRL-F5. Since this is Release mode, the compiled code does not have any debugging information. So, if I do not have any breakpoints, the execution times should be the same across the two, isn't it?!
(Assume that the Release and Debug modes are the typical configurations you get when you create a new Visual C++ project.)
The problem is that Windows drops in a special Debug Heap, if it detects that your program is running under a Debugger. This appears to happen at the OS level, and is independent of any Debug/Release mode settings for your compilation.
You can work around this 'feature' by setting an environment variable: _NO_DEBUG_HEAP=1
This same issue has been driving me nuts for a while; today I found the following, from whence this post is derived:
http://blogs.msdn.com/b/larryosterman/archive/2008/09/03/anatomy-of-a-heisenbug.aspx
"Start without debugging" just tells Windows to launch the app as it would normally run.
"Start with debugging" starts the VS debugger and has it run the app within the debugger.
This really doesn't have much to do with the debug/release build settings.
When you build the default 'debug' configuration of your app, you'll have the following main differences to the release build:
The emitted code won't be optimised, so is easier to debug because it more closely matches your source
The compiler & linker will output a .PDB file containing lots of extra information to help a debugger - the presence or absence of this information makes no difference to the performance of the code, just the ease of debugging.
Conditional macros like ASSERT and VERIFY will be no-ops in a release build but active in a debug build.
Each one of these items is independent and optional! You can turn any or all of them on or off and still run the code under the debugger, you just won't find life so easy.
When you run 'with debugging' things perform differently for several reasons:
The VS debugger is very inefficient at starting, partly because everything in VS is slow - on versions prior to VS2010 every pixel of the screen will be repainted about 30 times as the IDE staggers into debug mode with much flashing and flickering.
Depending on how things are configured, the debugger might spend a lot of time at startup trying to load symbols (i.e. PDB files) for lots and lots of OS components which are part of your process - it might try fetching these files over the web, which can take an age in some circumstances.
A number of activities your application normally does (loading DLLs, starting threads, handling exceptions) all cause the debugger to be alerted. This has the effect both of slowing them down and of making them tend to run sequentially.
IsDebuggerPresent() and OutputDebugString() behave differently depending on whether a debugger is attached.
IsDebuggerPresent() simply returns another value, so your program can react to this value and behave differently on purpose. OutputDebugString() returns much faster when there's no debugger attached, so if it's called lots of times you'll see that the program runs much faster without the debugger.
When running 'with debugging' the debug heap is used, even for release mode. This causes severe slowdowns in code using a lot of malloc/free or new/delete, which can happen in C++ code without you noticing it because libraries/classes tend to hide this memory management stuff from you.