I have compiled a cpp file with this command line: g++ -g test.cpp
It throws an exception at line 28. I want to investigate the cause by inspecting the variables in lldb. I set a break point at line 28 and run the a.out in lldb.
(lldb) n
Process 84233 stopped
* thread #1: tid = 0xa44b86, 0x00000001000017fb a.out`say(s=<unavailable>) + 987 at so.cpp:28, queue = 'com.apple.main-thread', stop reason = step over
frame #0: 0x00000001000017fb a.out`say(s=<unavailable>) + 987 at so.cpp:28
25 }
26 else{
27 s.insert(0, to_string(sz));
-> 28 s.erase(2, sz-1);
29 }
30 return s;
31 }
(lldb) po s
error: Couldn't materialize: couldn't get the value of variable s: variable not available
Errored out in Execute, couldn't PrepareToExecuteJITExpression
Why the error message? How can I inspect the variable s?
lldb version: lldb-320.4.115.3
g++ version: Configured with: --prefix=/Applications/Xcode6-Beta5.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.45.3) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.3.0
Thread model: posix
That error means the debug information does mention the variable, but says it has no storage location at the current PC.
That can be because the variable got optimized out (unlikely given you are just calling a function on the variable) or because the compiler flubbed the debug info for the variable and lost track of where it went.
Make sure you are compiling the code you are trying to debug at -O0 as there aren't many compilers that emit good debug information at higher optimization levels. If you are compiling at -O0, this is a compiler bug. You should probably report it to the gcc folks. You could see if you have better luck with clang. Otherwise, you have to read the assembly of the function to figure out where the variable actually lives, then tell the debugger to print the appropriately cast address.
I had this problem when I enabled the "Address Sanitizer" from my app scheme. Disable it fixed the issue.
I see this when I run a RELEASE (vs a DEBUG) build (Product->Scheme...->Edit Scheme...->Info, then set Build Configuration to "Debug".
I had this issue when compiling with the flag -Og. For some reason I was thinking that that meant 'optimize for debugging'. I don't think thats the case in reality. Removing that flag fixed the issue for me.
Related
I am new to C++ and want to print out a double value. It is not that I actually need to print that value, I just want to know what is going wrong here.
This is my code (HelloWorld.cpp):
#include <iostream>
int main() {
double i = 5.5;
std::cout << i << std::endl;
return 0;
}
Executing this with the debugger attached results in the following error:
Thread 1 hit Breakpoint 1, main () at src/HelloWorld.cpp:4
4 double i = 5.5;
Thread 1 received signal SIGSEGV, Segmentation fault.
0x00000000929ba260 in ?? ()
When I put a breakpoint in there, creating and assigning the variable is no problem. The error only occurs once the program is supposed to print that value. Executing the exe without the debugger results in no output at all. The same happens when I replace the double with a long double or float. Printing anything else works fine (Strings, char, int, short, etc.).
I am using Visual Studio Code and MinGW (x86_64-8.1.0-posix-seh-rt_v6-rev0). VS Code is using following files for compilation / debugging:
c_cpp_properties.json
launch.json
tasks.json
And here you can see the complete output, in case that helps.
Any Idea what I am doing wrong here? Thank you.
EDIT:
When compiling manually using g++ -g .\src\HelloWorld.cpp -std=c++11 -o HelloWorld.exe (or just g++ .\src\HelloWorld.cpp -o HelloWorld.exe) and running that from the console, the same happens (no output).
I installed MinGW from here using the following settings:
Version: 8.1.0
Architecture: x86_64
Threads: posix
Exception: seh
Build revision: 0
EDIT 2:
Found the problem. There was an old version of gcc lurking in my PATH (maybe from Visual Studio or MSSQL Server?). I just move the current gcc to the top of PATH and now it's working fine. Thank you all for your help!
As many pointed out, this should usually work. The problem was with my setup: I had an old version of gcc somewhere in my PATH variable (version 4.1). Moving the path of the newer version to the beginning of PATH resolves the issue. Thank you all for helping.
To check weather the same happens to you you can do the following: execute g++ --version in your project directory. Compare this with the output of g++.exe --version when you are in the directory where gcc is installed (for me, this was C:\Program Files\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin).
Is there any gcc option I can set that will give me the line number of the segmentation fault?
I know I can:
Debug line by line
Put printfs in the code to narrow down.
Edits:
bt / where on gdb give No stack.
Helpful suggestion
I don't know of a gcc option, but you should be able to run the application with gdb and then when it crashes, type where to take a look at the stack when it exited, which should get you close.
$ gdb blah
(gdb) run
(gdb) where
Edit for completeness:
You should also make sure to build the application with debug flags on using the -g gcc option to include line numbers in the executable.
Another option is to use the bt (backtrace) command.
Here's a complete shell/gdb session
$ gcc -ggdb myproj.c
$ gdb a.out
gdb> run --some-option=foo --other-option=bar
(gdb will say your program hit a segfault)
gdb> bt
(gdb prints a stack trace)
gdb> q
[are you sure, your program is still running]? y
$ emacs myproj.c # heh, I know what the error is now...
Happy hacking :-)
You can get gcc to print you a stacktrace when your program gets a SEGV signal, similar to how Java and other friendlier languages handle null pointer exceptions. See my answer here for more details:
how to generate a stacktace when my C++ app crashes ( using gcc compiler )
The nice thing about this is you can just leave it in your code; you don't need to run things through gdb to get the nice debug output.
If you compile with -g and follow the instructions there, you can use a command-line tool like addr2line to get file/line information from the output.
Run it under valgrind.
you also need to build with debug flags on -g
You can also open the core dump with gdb (you need -g though).
If all the preceding suggestions to compile with debugging (-g) and run under a debugger (gdb, run, bt) are not working for you, then:
Elementary: Maybe you're not running under the debugger, you're just trying to analyze the postmortem core dump. (If you start a debug session, but don't run the program, or if it exits, then when you ask for a backtrace, gdb will say "No stack" -- because there's no running program at all. Don't forget to type "run".) If it segfaulted, don't forget to add the third argument (core) when you run gdb, otherwise you start in the same state, not attached to any particular process or memory image.
Difficult: If your program is/was really running but your gdb is saying "No stack" perhaps your stack pointer is badly smashed. In which case, you may be a buffer overflow problem somewhere, severe enough to mash your runtime state entirely. GCC 4.1 supports the ProPolice "Stack Smashing Protector" that is enabled with -fstack-protector-all. It can be added to GCC 3.x with a patch.
There is no method for GCC to provide this information, you'll have to rely on an external program like GDB.
GDB can give you the line where a crash occurred with the "bt" (short for "backtrace") command after the program has seg faulted. This will give you not only the line of the crash, but the whole stack of the program (so you can see what called the function where the crash happened).
The No stack problem seems to happen when the program exit successfully.
For the record, I had this problem because I had forgotten a return in my code, which made my program exit with failure code.
After recently upgrading to g++ 4.8.1 I've found that debugging is completely impossible in gdb. g++ seems to hide all variables from gdb, regardless of optimization options. In the following session, runner.cpp is as follows:
#include <vector>
using namespace std;
int main(void) {
vector<int> arr;
int a = 3;
int b = 2;
b = a + 3;
arr.push_back(1);
arr.push_back(2);
arr.push_back(3);
arr.push_back(4);
return 0;
}
This is the result:
Script started on Tue 14 Jul 2015 01:11:14 PM PDT
me#ministation:~/Development/clib$ g++ -g -O0 runner.cpp
me#ministation:~/Development/clib$ gdb -q ./a.out
Reading symbols from /home/me/Development/clib/a.out...done.
(gdb) break 11
Breakpoint 1 at 0x40095c: file runner.cpp, line 11.
(gdb) run
Starting program: /home/me/Development/clib/a.out
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
Breakpoint 1, main () at runner.cpp:11
11 arr.push_back(1);
(gdb) print a
$1 = {i = {0, 1045149306}, d = 1.2904777690891933e-08} ## I have no idea what this means
(gdb) print b
$2 = {i = {0, 1068498944}, d = 0.0625}
(gdb) print arr
No symbol "arr" in current context.
(gdb) info locals
No locals.
(gdb) next
12 arr.push_back(2);
(gdb)
13 arr.push_back(3);
(gdb) print arr
No symbol "arr" in current context.
(gdb) next
14 arr.push_back(4);
(gdb)
16 return 0;
(gdb) print arr
No symbol "arr" in current context.
(gdb) q
A debugging session is active.
Inferior 1 [process 6392] will be killed.
Quit anyway? (y or n) y
me#ministation:~/Development/clib$
Script done on Tue 14 Jul 2015 01:12:05 PM PDT
I've seen somewhat similar posts where the -O0 flag was recommended, but it doesn't seem to work here. The exact same session after compiling with g++4.6 produces the expected results. Any ideas on what's causing this with g++4.8?
The particular problem here is that the meaning of the DW_AT_high_pc tag in the debug info has been extended to also mean an offset.
Originally, a function ranging from 0x804dd8e to 0x804ddae was encoded as
DW_AT_low_pc : 0x804dd8e
DW_AT_high_pc : 0x804ddae
Now it also can be encoded as
DW_AT_low_pc : 0x804dd8e
DW_AT_high_pc : 0x20
which saves a bit of space in the debug info.
Older versions of GDB only recognize the first version, and interpret the second in a way that there can't be any variables in this range.
Possible solutions are to compile with -gdwarf-2 or to upgrade GDB.
gdb and gcc need to be compatible versions when it comes to debug format (and they are generally quite well compatible over many versions, but SOMETIMES compatibility is broken from one version of a compiler to another).
I have had exactly the same problem. The solution is either to throw some flag at gcc to compile with "older style debug format", or to upgrade the version of gdb to one that "works" with the debug format given by the newer version of gcc.
It would be NICE if gdb actually said something like "Your debug format is X, you need debug format Y or Z for gdb to work correctly", but I'm not 100% sure that can be reliably determined (for example when a bug is found in the generation that is fixed, and need the corresponding fix in the debugger, because the same bug appears in both the "produce" and "consume" parts of the debug-symbol handler - so an older, buggy version can't read the newer unbuggy format and vice versa)
I have this C function in a huge code:
void test() {
char *arg[] = {"/bin/sh", 0};
execve("/bin/sh", arg, 0);
}
I am trying to debug this code using gdb
(gdb) call test()
process 1948 is executing new program: /bin/dash
warning: Selected architecture i386:x86-64 is not compatible with reported target architecture i386
Architecture of file not recognized.
An error occurred while in a function called from GDB.
Evaluation of the expression containing the function
(test) will be abandoned.
When the function is done executing, GDB will silently stop.
Hence the shell is not spawning. How to go about it?
gdb isn't allowing you to exec a binary with a different architecture, even though it's compatible on your platform. The same occurs if you try to exec a 32bit executable from a 64bit one. This occurs on the latest version (7.5.1) of gdb as well.
If you can compile your code as 32bit without it causing other problems, it would be a workaround.
As per Hasturkun's comment, there is a patch available here.
I have just moved from Ubuntu 10.04 to the new version of 11.04 and when I try to debug with ddd/gdb I cannot set anymore breakpoints nor see the flow while the debugger is executing my program.
I receive error messages saying
(gdb)b MyFile.cpp:27
No line 27 in file "MyFile.cpp".
When I start running my application calling r I also can see the following text message that looks to me related to my issue. The debuggers traps all assertions but I cannot stop at any point.
(gdb) r
BFD: /lib/x86_64-linux-gnu/libc.so.6: invalid relocation type 37
BFD: BFD (GNU Binutils) 2.18.50.20080226 assertion fail elf64-x86-64.c:278
BFD: /lib/x86_64-linux-gnu/libc.so.6: invalid relocation type 37
BFD: BFD (GNU Binutils) 2.18.50.20080226 assertion fail elf64-x86-64.c:278
If I want to see the file, the debuggers open the file with me but I receive the following error message
(gdb) list MyFile.cpp:27
Line number 27 is out of range for "MyFile.cpp".
Can you help me?
I read some forum asking to check the result of info source and info sources and this is what I have but I don't know what to do with it.
(gdb) list MyFile.cpp:27
Line number 27 is out of range for "MyFile.cpp".
(gdb) info source
Current source file is /usr/local/include/boost/exception/exception.hpp
Compilation directory is /home/emanueler/trunk/tools/myAppBinary
Located in /usr/local/include/boost/exception/exception.hpp
Contains 436 lines.
Source language is c++.
Compiled with unknown debugging format.
Includes preprocessor macro info.
Why it says "Compiled with unknown debugging format." when I am giving the -g option at compiler?
It seems all the compiling related tools were also updated, including GCC. It would be best if you recompile your entire application in this new environment before trying to debug it again.
You can do a simple test for check that your toolchain is ok. Write a small hello world app, compile it with -g and try to set a breakpoint on the cout line.