I am debugging a binary (assembly only) using GDB 7.1 compiled via MacPorts for Snow Leopard. I am interested in a specific address that I found using find gdb command. So that, it is a valid address indeed:
(gdb) printf "%s\n", 0x00196f34
bruno
(gdb)
The problem is whenever I set a watchpoint for it (watch *0x00196f34) AND it gets accessed, the system crashes and reboots right away.
I noticed hardware watchpoint is enabled then, expecting a less severe result, I switched to software watchpoint using set can-use-hw-watchpoints 0 but this didn't fix the problem.
I tried to use gdb 6.3 version that comes with Xcode and watch works fine. There is a difference I noticed when setting such watch for both 6.3 and 7.1:
for gdb 6.3
(gdb) watch *0x00196f34
Watchpoint 1: *0x00196f34
(gdb) info breakpoints
Num Type Disp Enb Address What
1 watchpoint keep y *0x00196f34
for gdb 7.1
(gdb) watch *0x00196f34
Hardware watchpoint 1: *1666868
(gdb) info breakpoints
Num Type Disp Enb Address What
1 hw watchpoint keep y *1666868
Why does the older gdb, which works, print in hex while the new one translates the address into decimal number? I still want to work with gdb 7, so any clue what is it going on here?
Bruno Velasco
Related
GDB does not set the same breakpoints in created forks. However, it should do it according to the documentation (if I understand it correctly):
If you have a breakpoint set on main in your original program, the breakpoint will also be set on the child process’s main.
I am also getting the following error for each set breakpoint:
Error in re-setting breakpoint 7: Cannot access memory at address 0x606682
Error in re-setting breakpoint 8: Cannot access memory at address 0x606682
Error in re-setting breakpoint 10: Cannot access memory at address 0x606682
It's probably worth to mention that I can set breakpoints after the fork was created as follows:
catch fork
cont
step
break file.cc:42
cont
GDB version is GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
I am learning debugging with gdb and registers, but I am stuck in one point. As an instruction, I should print
print $esp
result: $1 = -9008
but I was expecting such result:
$2 = (void *) 0x7fffffffdcd0
In the next command, I need to enter that command:
x/24 $esp
Saying that no access to that register
Cannot access memory at address 0xffffffffffffdce0
You appear to be reading instructions from some i386 tutorial, while using x86_64 (64-bit) platform.
On x86_64, there is no $esp register, only the $rsp one.
Also note that calling convention on x86_64 is different (arguments are not necessarily passed on stack), so your best course of action is to either find a new 64-bit tutorial, or to debug 32-bit target (usually you can build and run 32-bit programs on 64-bit hosts by compiling and linking them with gcc -m32 ...).
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 am using 3 HP-UX PA RISC machines for testing. My binary is failing on one PA RISC machine where as others it working. Note that, even though binary is executed with version check i.e. it just print version and exit and don't perform any other operation , still binary is giving segmentation fault. what could be probable reason for Segmentation fault. It is important to me to find out root cause of the failure on one box. As program is working on 2 HP-UX, it seems that it is environment issue?
I tried to copy same piece of code (i.e. declare variables, print version and exit) in test program and build with same compilation options but it is working. Here is gdb output for the program.
$ gdb prg_us
Detected 64-bit executable.
Invoking /opt/langtools/bin/gdb64.
HP gdb 5.4.0 for PA-RISC 2.0 (wide), HP-UX 11.00
and target hppa2.0w-hp-hpux11.00.
Copyright 1986 - 2001 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 5.4.0 (based on GDB) is covered by the
GNU General Public License. Type "show copying" to see the conditions to
change it and/or distribute copies. Type "show warranty" for warranty/support.
..
(gdb) b 5573
Breakpoint 1 at 0x4000000000259e04: file pmgreader.c, line 5573 from /tmp/test/prg_us.
(gdb) r -v
Starting program: /tmp/test/prg_us -v
Breakpoint 1, main (argc=2, argv=0x800003ffbfff05f8) at pmgreader.c:5573
5573 if (argc ==2 && strcmp (argv[1], "-v") == 0)
Current language: auto; currently c++
(gdb) n
5575 printf ("%s", VER);
(gdb) n
5576 exit(0);
(gdb) n
Program received signal SIGSEGV, Segmentation fault
si_code: 0 - SEGV_UNKNOWN - Unknown Error.
0x800003ffbfb9e130 in real_free+0x480 () from /lib/pa20_64/libc.2
(gdb)
What should be probable cause? why it is working on one and not on another?
Just a long shot - are you including both stdio.h and stdlib.h so the prototypes for printf() and exit() are known to the compiler?
Actually, after a bit more thought (and noticing that C++ is in the mix), you may have some static object initialization causing problems (possibly corrupting the heap?).
Unfortunately, it looks like valgrind is not supported on PA-RISC - is there some similar tool on PA-RISC you can run? If not, it might be worthwhile running valgrind on an x64 build of your program if it's not too difficult to set that up.
Michael Burr already hinted at the problem: it's a global object.
Notice that the crash is from a free function. That indicates a memory deallocation, and in turn a destructor. This makes sense given the context: global destructors run after exit(0). A stack trace will show more detail.
I have used two different versions of GDB, both give problems in the following code:
Trimmed down code in MyFile.h:
template<class T>
struct ABC: PQR<T> {
void flow(PP pp) {
const QX qx = XYZ<Z>::foo(pp); // Trying to set a breakpoint here, line no. 2533
ASSERTp(qx >= last_qx());
}
}
GDB 7.1:
Reading symbols from /path_to_exec/exec...done.
(gdb) break MyFile.h:2533
Note: breakpoint 1 also set at pc 0x121.
Note: breakpoint 1 also set at pc 0x121.
Note: breakpoint 1 also set at pc 0x121.
Note: breakpoint 1 also set at pc 0x156.
Note: breakpoint 1 also set at pc 0x156.
Note: breakpoint 1 also set at pc 0x121.
Note: breakpoint 1 also set at pc 0x121.
Note: breakpoint 1 also set at pc 0x121.
Note: breakpoint 1 also set at pc 0x121.
Note: breakpoint 1 also set at pc 0x121.
Note: breakpoint 1 also set at pc 0x121.
Note: breakpoint 1 also set at pc 0x156.
Note: breakpoint 1 also set at pc 0x156.
Note: breakpoint 1 also set at pc 0x121.
Breakpoint 1 at 0x44e5c4: file PacketEngine.h, line 2533. (23 locations)
(gdb) run
Starting program: /path_to_exec/exec -options
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x121: Input/output error.
Cannot insert breakpoint 1.
Error accessing memory address 0x156: Input/output error.
Why is it trying to set 23 breakpoints for one? And further down, it is giving error on run
GDB 6.3:
This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db library "/lib64/tls/libthread_db.so.1".
(gdb) break MyFile.h:2533
No line 2533 in file "MyFile.h".
At start of the program, it doesn't even accept the breakpoint
If I break in function ASSERTp, it breaks. Then. if I go "UP", and type break, it successfully inserts breakpoint (break MyFile.h:2533). [thus somehow it finds the file/line after the program actually runs]. However, despite the breakpoint being set, on rerunning the program it does not stop at line 2533 but 2534 only (breakpoint in function ASSERTp).
My questions:
1) Can someone please help me solve this?
2) I have often had problems with template code and GDB. Is there any good & free C++ debugger for templates?
3) Not really important, but a side question if it matters: Which version is preferable? The 7.1 seems to be more buggy, but I remember on some runs, it gives less problems.
System info:
uname -a
Linux ... 2.6.9-67.ELsmp #1 SMP Fri Nov 16 12:49:06 EST 2007 x86_64 x86_64 x86_64 GNU/Linux
file /usr/bin/gdb #### GDB 6.3
/usr/bin/gdb: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), stripped
file ~/local/bin/gdb #### GDB 7.1
/home/user/local/bin/gdb: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), not stripped
file /path_to_exec/exec
/path_to_exec/exec: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), not stripped
I am not of any other debugger for linux, but I never experienced such problems as you explained.
You formulated your question really nice (so you probably did), but did you compile your sources with debug symbols?
EDIT
btw I haven't tried gdb 7.1 - only 6.8 version. If you think it is very buggy, try using the last version of the 6 version.
I have seen something similar (using GDB 7.0) where a breakpoint set in a template function is never hit.
Our project is built using an old version of G++ (much older than the version shipped in my distro). I found that by building a version of GDB using the same compiler we develop with that the problem was solved.
gdb sets a different breakpoint for each instantiated template, i.e for each different type assumed by T (and perhaps Z) in your program. However, the addresses that it is trying to set breakpoints at 0x121 seem to be too low and probably correspond to some system locations. This is probably why gdb can't set the breakpoints.
You should try gdb 7.2, perhaps that will help.
Also, e2dbg is a different type of debugger for Linux, but it is not as mature as gdb.
http://www.eresi-project.org/wiki/TheEmbeddedELFDebugger