[PATCH] Seg fault whilst stepping when watch set

[PATCH] Seg fault whilst stepping when watch set

[David Lecomber]

[-- Attachment #1: Type: text/plain, Size: 973 bytes --]

Unfortunately I can't reproduce this without the intel compiler/f90. 
However, the relevant GDB output was:
(gdb) r
Starting program: /home/david/f90demo
[Thread debugging using libthread_db enabled]
[New Thread -151084928 (LWP 24298)]
[Switching to Thread -151084928 (LWP 24298)]

Breakpoint 1, 0x08089e8a in main ()
(gdb) step
Single stepping until exit from function main,
which has no line number information.

sample () at f90demo.f90:72
72      CALL MPI_INIT(ierr)
Current language:  auto; currently fortran
(gdb) watch i
Hardware watchpoint 2: i
(gdb) step
Error in re-setting breakpoint 2:
No symbol "i" in current context.
<bang, seg fault>

This being line when breakpoint.c:949 calls evaluate_expression where
exp is 0.

I propose the attached, which has fixed this seg fault on my system. 
Permission to commit?

2004-10-17    <dsl@sources.redhat.com>

	* breakpoint.c (insert_bp_location): Regenerate expression in
	breakpoint owner for watchpoints if null.



[-- Attachment #2: watch.patch --]
[-- Type: text/x-patch, Size: 767 bytes --]

Index: gdb/breakpoint.c
===================================================================
RCS file: /cvs/src/src/gdb/breakpoint.c,v
retrieving revision 1.183
diff -c -p -r1.183 breakpoint.c
*** gdb/breakpoint.c	8 Oct 2004 17:30:46 -0000	1.183
--- gdb/breakpoint.c	17 Oct 2004 00:01:44 -0000
*************** insert_bp_location (struct bp_location *
*** 946,951 ****
--- 946,953 ----
  	     Make sure the value returned isn't lazy; we use
  	     laziness to determine what memory GDB actually needed
  	     in order to compute the value of the expression.  */
+ 	  if (!bpt->owner->exp) 
+ 	    bpt->owner->exp = parse_expression (bpt->owner->exp_string);
  	  v = evaluate_expression (bpt->owner->exp);
  	  VALUE_CONTENTS (v);
  	  value_release_to_mark (mark);

Re: [PATCH] Seg fault whilst stepping when watch set [ping!]

[David Lecomber]

[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]

One week ping..


Ping!!

d.

On Sun, 2004-10-17 at 01:16, David Lecomber wrote:
> Unfortunately I can't reproduce this without the intel compiler/f90. 
> However, the relevant GDB output was:
> (gdb) r
> Starting program: /home/david/f90demo
> [Thread debugging using libthread_db enabled]
> [New Thread -151084928 (LWP 24298)]
> [Switching to Thread -151084928 (LWP 24298)]
> 
> Breakpoint 1, 0x08089e8a in main ()
> (gdb) step
> Single stepping until exit from function main,
> which has no line number information.
> 
> sample () at f90demo.f90:72
> 72      CALL MPI_INIT(ierr)
> Current language:  auto; currently fortran
> (gdb) watch i
> Hardware watchpoint 2: i
> (gdb) step
> Error in re-setting breakpoint 2:
> No symbol "i" in current context.
> <bang, seg fault>
> 
> This being line when breakpoint.c:949 calls evaluate_expression where
> exp is 0.
> 
> I propose the attached, which has fixed this seg fault on my system. 
> Permission to commit?
> 
> 2004-10-17    <dsl@sources.redhat.com>
> 
> 	* breakpoint.c (insert_bp_location): Regenerate expression in
> 	breakpoint owner for watchpoints if null.
> 
> 

[-- Attachment #2: watch.patch --]
[-- Type: text/x-patch, Size: 767 bytes --]

Index: gdb/breakpoint.c
===================================================================
RCS file: /cvs/src/src/gdb/breakpoint.c,v
retrieving revision 1.183
diff -c -p -r1.183 breakpoint.c
*** gdb/breakpoint.c	8 Oct 2004 17:30:46 -0000	1.183
--- gdb/breakpoint.c	17 Oct 2004 00:01:44 -0000
*************** insert_bp_location (struct bp_location *
*** 946,951 ****
--- 946,953 ----
  	     Make sure the value returned isn't lazy; we use
  	     laziness to determine what memory GDB actually needed
  	     in order to compute the value of the expression.  */
+ 	  if (!bpt->owner->exp) 
+ 	    bpt->owner->exp = parse_expression (bpt->owner->exp_string);
  	  v = evaluate_expression (bpt->owner->exp);
  	  VALUE_CONTENTS (v);
  	  value_release_to_mark (mark);

Re: [PATCH] Seg fault whilst stepping when watch set [ping!] [in breakpoint.c]

[David Lecomber]

Two week ping!!!!  This really is an obviously harmless patch, not
necessarily an obvious patch, but it's one that can only stop a segfault
that would otherwise happen, so could someone give the ok please..

d.


On Mon, 2004-10-25 at 17:06, David Lecomber wrote:
> One week ping..
> 
> 
> Ping!!
> 
> d.
> 
> On Sun, 2004-10-17 at 01:16, David Lecomber wrote:
> > Unfortunately I can't reproduce this without the intel compiler/f90. 
> > However, the relevant GDB output was:
> > (gdb) r
> > Starting program: /home/david/f90demo
> > [Thread debugging using libthread_db enabled]
> > [New Thread -151084928 (LWP 24298)]
> > [Switching to Thread -151084928 (LWP 24298)]
> > 
> > Breakpoint 1, 0x08089e8a in main ()
> > (gdb) step
> > Single stepping until exit from function main,
> > which has no line number information.
> > 
> > sample () at f90demo.f90:72
> > 72      CALL MPI_INIT(ierr)
> > Current language:  auto; currently fortran
> > (gdb) watch i
> > Hardware watchpoint 2: i
> > (gdb) step
> > Error in re-setting breakpoint 2:
> > No symbol "i" in current context.
> > <bang, seg fault>
> > 
> > This being line when breakpoint.c:949 calls evaluate_expression where
> > exp is 0.
> > 
> > I propose the attached, which has fixed this seg fault on my system. 
> > Permission to commit?
> > 
> > 2004-10-17    <dsl@sources.redhat.com>
> > 
> > 	* breakpoint.c (insert_bp_location): Regenerate expression in
> > 	breakpoint owner for watchpoints if null.
> > 
> > 

Re: [PATCH] Seg fault whilst stepping when watch set [ping!] [in breakpoint.c]

[Eli Zaretskii]

> From: David Lecomber <david@streamline-computing.com>
> Date: Mon, 01 Nov 2004 22:11:36 +0000
> 
> Two week ping!!!!  This really is an obviously harmless patch, not
> necessarily an obvious patch, but it's one that can only stop a segfault
> that would otherwise happen, so could someone give the ok please..

Sorry, I missed the original post somehow.

Can you post a short test program, preferably in C, that can be used
to reproduce this problem?  I don't think I've ever seen such crashes.

TIA

Re: [PATCH] Seg fault whilst stepping when watch set [ping!] [in breakpoint.c]

[Eli Zaretskii]

[Please keep the discussion on the mailing list.]
> From: David Lecomber <david@streamline-computing.com>
> Date: Tue, 02 Nov 2004 08:54:00 +0000
> 
> > Can you post a short test program, preferably in C, that can be used
> > to reproduce this problem?  I don't think I've ever seen such crashes.
> 
> If only I could!  The only example I can make it happen with is using
> the Intel Fortran Compiler for a piece of F90. 

Then please post an annotated debug session (debugging GDB with
itself, where the inferior GDB has the F90 compiled program as its
debuggee) which shows the problem and explains how you arrived at the
conclusion that the patch you suggested is the correct one.  I need to
understand the details of these crashes to be able to consider the
validity of the patch.

> I can supply you with the binary if you'd like to have a go, but I
> don't see any other way we'll be able to produce this.

If the binary is short, then you could alternatively mail it to me as
a binary attachment together with the source and instructions how to
reproduce the crash.

Re: [PATCH] Seg fault whilst stepping when watch set [ping!] [in breakpoint.c]

[David Lecomber]

Hi Eli,

Breakpoint 1, 0x08089e8a in main ()
(gdb) step
Single stepping until exit from function main,
which has no line number information.
sample () at f90demo.f90:72
72      CALL MPI_INIT(ierr)
Current language:  auto; currently fortran
(gdb) watch i
Hardware watchpoint 2: i
(gdb) n
Error in re-setting breakpoint 2:
No symbol "i" in current context.
 
{seg fault...} and in the other GDB:
Program received signal SIGSEGV, Segmentation fault.
evaluate_subexp (expect_type=0x0, exp=0x0, pos=0xbfffef34,
noside=EVAL_NORMAL) at eval.c:71
71        return (*exp->language_defn->la_exp_desc->evaluate_exp)


#0  evaluate_subexp (expect_type=0x0, exp=0x0, pos=0xbfffef34,
noside=EVAL_NORMAL) at eval.c:71
#1  0x080d3fa9 in evaluate_expression (exp=0x0) at eval.c:161
#2  0x080c4341 in insert_bp_location (bpt=0x82d8458,
tmp_error_stream=0x82de608, disabled_breaks=0xbfffefd0,
process_warning=0xbfffefd4,
    hw_breakpoint_error=0xbfffefd8) at breakpoint.c:949
#3  0x080c45a7 in insert_breakpoints () at breakpoint.c:1149
#4  0x080f43cd in keep_going (ecs=0xbffff0d0) at infrun.c:2716
#5  0x080f2f47 in handle_inferior_event (ecs=0xbffff0d0) at
infrun.c:2543
#6  0x080f270b in wait_for_inferior () at infrun.c:991
#7  0x080f253d in proceed (addr=1, siggnal=TARGET_SIGNAL_DEFAULT,
step=1) at infrun.c:814
#8  0x080efe9b in step_1 (skip_subroutines=1, single_inst=0,
count_string=0x0) at infcmd.c:688

(gdb) p exp
$1 = (struct expression *) 0x0

Looking at frame 2:

#2  0x080c4341 in insert_bp_location (bpt=0x82d8458,
tmp_error_stream=0x82de608, disabled_breaks=0xbfffefd0,
process_warning=0xbfffefd4,
    hw_breakpoint_error=0xbfffefd8) at breakpoint.c:949
949               v = evaluate_expression (bpt->owner->exp);


(gdb) p *bpt
$5 = {next = 0x82de5d8, loc_type = bp_loc_hardware_watchpoint, owner =
0x835f3f0, inserted = 0 '\0', duplicate = 0 '\0', address = 0, section =
0x0,
  shadow_contents = '\0' <repeats 15 times>, requested_address = 0}
(gdb) p *(bpt->owner)
$6 = {next = 0x83ac680, type = bp_hardware_watchpoint, enable_state =
bp_enabled, disposition = disp_donttouch, number = 2, loc = 0x82d8458,
line_number = 0,
  source_file = 0x0, silent = 0 '\0', ignore_count = 0, commands = 0x0,
frame_id = {stack_addr = 0, code_addr = 0, special_addr = 0,
stack_addr_p = 0,
    code_addr_p = 0, special_addr_p = 0}, cond = 0x0, addr_string = 0x0,
language = language_fortran, input_radix = 10, cond_string = 0x0,
exp_string = 0x835d408 "i",
  exp = 0x0, exp_valid_block = 0x841723c, val = 0x835f8d8, val_chain =
0x0, related_breakpoint = 0x83ac680, watchpoint_frame = {stack_addr =
3221223780,
    code_addr = 134526326, special_addr = 0, stack_addr_p = 1,
code_addr_p = 1, special_addr_p = 0}, thread = -1, hit_count = 0,
dll_pathname = 0x0,
  triggered_dll_pathname = 0x0, forked_inferior_pid = 0, exec_pathname =
0x0, ops = 0x0, from_tty = 0, flag = 0, pending = 0}

So bpt->owner->exp is clearly null, which makes it a bad idea to
evaluate it ;-)

> If the binary is short, then you could alternatively mail it to me as
> a binary attachment together with the source and instructions how to
> reproduce the crash.

Curiously on Fedora 2 I get a seg fault, and

Error in re-setting breakpoint 2:
No symbol "i" in current context.

But on Redhat 9, I get no segfault but do see the above error repeated 3
times..  

With my patch, it works fine, for me ;-)

d.

Re: [PATCH] Seg fault whilst stepping when watch set [ping!] [in breakpoint.c]

[David Lecomber]

Hi Eli,

Ping * 3!  

d.
On Wed, 2004-11-03 at 12:08, David Lecomber wrote:
> Hi Eli,
> 
> Breakpoint 1, 0x08089e8a in main ()
> (gdb) step
> Single stepping until exit from function main,
> which has no line number information.
> sample () at f90demo.f90:72
> 72      CALL MPI_INIT(ierr)
> Current language:  auto; currently fortran
> (gdb) watch i
> Hardware watchpoint 2: i
> (gdb) n
> Error in re-setting breakpoint 2:
> No symbol "i" in current context.
>  
> {seg fault...} and in the other GDB:
> Program received signal SIGSEGV, Segmentation fault.
> evaluate_subexp (expect_type=0x0, exp=0x0, pos=0xbfffef34,
> noside=EVAL_NORMAL) at eval.c:71
> 71        return (*exp->language_defn->la_exp_desc->evaluate_exp)
> 
> 
> #0  evaluate_subexp (expect_type=0x0, exp=0x0, pos=0xbfffef34,
> noside=EVAL_NORMAL) at eval.c:71
> #1  0x080d3fa9 in evaluate_expression (exp=0x0) at eval.c:161
> #2  0x080c4341 in insert_bp_location (bpt=0x82d8458,
> tmp_error_stream=0x82de608, disabled_breaks=0xbfffefd0,
> process_warning=0xbfffefd4,
>     hw_breakpoint_error=0xbfffefd8) at breakpoint.c:949
> #3  0x080c45a7 in insert_breakpoints () at breakpoint.c:1149
> #4  0x080f43cd in keep_going (ecs=0xbffff0d0) at infrun.c:2716
> #5  0x080f2f47 in handle_inferior_event (ecs=0xbffff0d0) at
> infrun.c:2543
> #6  0x080f270b in wait_for_inferior () at infrun.c:991
> #7  0x080f253d in proceed (addr=1, siggnal=TARGET_SIGNAL_DEFAULT,
> step=1) at infrun.c:814
> #8  0x080efe9b in step_1 (skip_subroutines=1, single_inst=0,
> count_string=0x0) at infcmd.c:688
> 
> (gdb) p exp
> $1 = (struct expression *) 0x0
> 
> Looking at frame 2:
> 
> #2  0x080c4341 in insert_bp_location (bpt=0x82d8458,
> tmp_error_stream=0x82de608, disabled_breaks=0xbfffefd0,
> process_warning=0xbfffefd4,
>     hw_breakpoint_error=0xbfffefd8) at breakpoint.c:949
> 949               v = evaluate_expression (bpt->owner->exp);
> 
> 
> (gdb) p *bpt
> $5 = {next = 0x82de5d8, loc_type = bp_loc_hardware_watchpoint, owner =
> 0x835f3f0, inserted = 0 '\0', duplicate = 0 '\0', address = 0, section =
> 0x0,
>   shadow_contents = '\0' <repeats 15 times>, requested_address = 0}
> (gdb) p *(bpt->owner)
> $6 = {next = 0x83ac680, type = bp_hardware_watchpoint, enable_state =
> bp_enabled, disposition = disp_donttouch, number = 2, loc = 0x82d8458,
> line_number = 0,
>   source_file = 0x0, silent = 0 '\0', ignore_count = 0, commands = 0x0,
> frame_id = {stack_addr = 0, code_addr = 0, special_addr = 0,
> stack_addr_p = 0,
>     code_addr_p = 0, special_addr_p = 0}, cond = 0x0, addr_string = 0x0,
> language = language_fortran, input_radix = 10, cond_string = 0x0,
> exp_string = 0x835d408 "i",
>   exp = 0x0, exp_valid_block = 0x841723c, val = 0x835f8d8, val_chain =
> 0x0, related_breakpoint = 0x83ac680, watchpoint_frame = {stack_addr =
> 3221223780,
>     code_addr = 134526326, special_addr = 0, stack_addr_p = 1,
> code_addr_p = 1, special_addr_p = 0}, thread = -1, hit_count = 0,
> dll_pathname = 0x0,
>   triggered_dll_pathname = 0x0, forked_inferior_pid = 0, exec_pathname =
> 0x0, ops = 0x0, from_tty = 0, flag = 0, pending = 0}
> 
> So bpt->owner->exp is clearly null, which makes it a bad idea to
> evaluate it ;-)
> 
> > If the binary is short, then you could alternatively mail it to me as
> > a binary attachment together with the source and instructions how to
> > reproduce the crash.
> 
> Curiously on Fedora 2 I get a seg fault, and
> 
> Error in re-setting breakpoint 2:
> No symbol "i" in current context.
> 
> But on Redhat 9, I get no segfault but do see the above error repeated 3
> times..  
> 
> With my patch, it works fine, for me ;-)
> 
> d.
> 

Re: [PATCH] Seg fault whilst stepping when watch set [ping!] [in breakpoint.c]

[Eli Zaretskii]

> From: David Lecomber <david@streamline-computing.com>
> Date: Wed, 03 Nov 2004 12:08:27 +0000
> 
> Curiously on Fedora 2 I get a seg fault, and
> 
> Error in re-setting breakpoint 2:
> No symbol "i" in current context.
> 
> But on Redhat 9, I get no segfault but do see the above error repeated 3
> times..  

Hmm... Fedora?  Could that be a side-effect of the exec-shield
feature?

Since I don't have access to a Fedora machine, I cannot debug this
myself.  I will try to figure out what happens using your session
transcript.  Stay tuned.