Bug#520651: GDB crashes on watchpoints with illegal addresses
On Sun, Mar 22, 2009 at 01:45:59PM -0400, Daniel Jacobowitz wrote: : My mistake: I have the GDB from experimental installed. It works : there. I need to update unstable. The problem as I experience is on Lenny. Haven't tried experimental or unstable (yet). Claus -- Claus Fischer http://www.clausfischer.com/ signature.asc Description: Digital signature
Bug#520651: GDB crashes on watchpoints with illegal addresses
On Sun, Mar 22, 2009 at 03:04:23PM +0100, Claus Fischer wrote: > r# gives the following output > - > Starting program: /home/cfischer/tmp/tt > Error in re-setting breakpoint 3: Cannot access memory at address > 0x777e2f90 > Error in re-setting breakpoint 3: Cannot access memory at address > 0x777e2f90 > Error in re-setting breakpoint 3: Cannot access memory at address > 0x777e2f90 > Cannot access memory at address 0x777e2f90 > (gdb) > Debugger aborted > - r post-prompt Starting program: /home/drow/gdbtest starting breakpoint 1 Breakpoint 1, frame-begin 0 0x40052b main (argc=1, argv=0x7fffe068) at gdbtest.c:7 source /home/drow/gdbtest.c:7:95:beg:0x40052b stopped pre-prompt (gdb) prompt My mistake: I have the GDB from experimental installed. It works there. I need to update unstable. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#520651: GDB crashes on watchpoints with illegal addresses
Here is an example that works for me.
Environment:
Debian Lenny amd64
8 GB RAM (probably doesn't matter)
Linux 2.6.26-1-amd64
echo 0 >/proc/sys/kernel/randomize_va_space # important!
linux-image-amd64 2.6.26+17
gcc 4:4.3.2-2
gdb 6.8-3
emacs 22.2+2-5
Code:
---
/* gcc -W -Wall -Wextra -O0 -g3 -o tt tt.c
*/
#include
#include
#include
int main(int argc, char *argv[])
{
int *arr = 0;
if (argc)
{
arr = malloc(100 * sizeof(int));
arr[30] = 17;
printf("arr[30] = %d\n",arr[30]);
argv = argv;
}
return 0;
}
---
Compile: gcc -W -Wall -Wextra -O0 -g3 -o tt tt.c
Debug (in Emacs): emacs &
M-x gdb
gdb --annotate=3 tt
b main
r # stops in main
b 16 # the printf line
c
p arr[30]# gives $1 = 17
p &arr[30] # gives $2 = (int *) 0x777e2f90 on my system
watch *(int *) 0x777e2f90
# gives Hardware watchpoint 3: *(int *) 140737345630096
c# gives Program exited normally
r# gives the following output
-
Starting program: /home/cfischer/tmp/tt
Error in re-setting breakpoint 3: Cannot access memory at address 0x777e2f90
Error in re-setting breakpoint 3: Cannot access memory at address 0x777e2f90
Error in re-setting breakpoint 3: Cannot access memory at address 0x777e2f90
Cannot access memory at address 0x777e2f90
(gdb)
Debugger aborted
-
--
Claus Fischer
http://www.clausfischer.com/
signature.asc
Description: Digital signature
Bug#520651: GDB crashes on watchpoints with illegal addresses
On Sat, Mar 21, 2009 at 04:59:34PM +0100, Claus Fischer wrote: > With the latest gdb, a watchpoint which points into allocated memory > that is not available at process start, will not only cause the > program but also gdb to crash and abort. Can you show me an example debug session where this happens? I've used this feature as recently as yesterday. It worked fine, and in fact I was very happy with it - you used to get GDB errors on startup but now it will detect the first write even if memory was previosuly unmapped. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#520651: GDB crashes on watchpoints with illegal addresses
Package: gdb Version: 6.8-3 Summary: The latest gdb will usually crash as a consequence of a watchpoint outside the process's memory range. Older gdb's would sometimes try to disable the watchpoint instead. In a debugging session of a large program, it is often necessary to trace changes to memory locations with the watch command. To make it work across modules/functions, it needs to be done like this: gdb> p some->path->to[some].variable->location 73 gdb> p &some->path->to[some].variable->location (int*)0x12345678 gdb> watch *(int*)0x12345678 Sometimes it is then necessary to restart the program in order to find out how and when a 'bad' value has been set. With the latest gdb, a watchpoint which points into allocated memory that is not available at process start, will not only cause the program but also gdb to crash and abort. This is extremely annoying, because one loses the whole debugging context (mainly other breakpoints) and has to reconstruct the debugging session very painfully. Wishlist for improvements: 1) Don't let gdb crash on that 2) Just disable the watchpoint if memory is not available on startup 3) Automatically reenable the watchpoint when memory becomes available 4) Provide a gdb command that combines the steps of a) take-address-of-an-object b) watch memory-where-object-is e.g. a command like watchbyaddr Claus -- Claus Fischer http://www.clausfischer.com/ signature.asc Description: Digital signature
