[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.

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

[David Lecomber]

> Also, last time we talked, I asked whether this could be due to the
> Fedora exec-shield feature, but didn't see any response to that.
> Could you please check that?

I'm not sure how to verify that one - the seg fault happens running as
either root or normal user, if that's related..

Thanks for looking at this bug, here's the latest stack trace and
session log for current CVS:

Program received signal SIGSEGV, Segmentation fault.
evaluate_subexp (expect_type=0x0, exp=0x0, pos=0xbfffed14,
noside=EVAL_NORMAL) at eval.c:71
71        return (*exp->language_defn->la_exp_desc->evaluate_exp)
(gdb) bt
#0  evaluate_subexp (expect_type=0x0, exp=0x0, pos=0xbfffed14,
noside=EVAL_NORMAL) at eval.c:71
#1  0x080f120d in evaluate_expression (exp=0x0) at eval.c:161
#2  0x080e159d in insert_bp_location (bpt=0x85208d0,
tmp_error_stream=0x8493008, disabled_breaks=0xbfffedb0,
    process_warning=0xbfffedb4, hw_breakpoint_error=0xbfffedb8) at
breakpoint.c:949
#3  0x080e1817 in insert_breakpoints () at breakpoint.c:1149
#4  0x081118f9 in keep_going (ecs=0xbfffeeb0) at infrun.c:2848
#5  0x0810ff76 in handle_inferior_event (ecs=0xbfffeeb0) at
infrun.c:2672
#6  0x0810f617 in wait_for_inferior () at infrun.c:996
#7  0x0810f3e5 in proceed (addr=1, siggnal=TARGET_SIGNAL_HUP, step=1) at
infrun.c:816
#8  0x0810c9c3 in step_1 (skip_subroutines=1, single_inst=0,
count_string=0x0) at infcmd.c:688
#9  0x0810c77e in next_command (count_string=0x0, from_tty=1) at
infcmd.c:585
#10 0x080c1b7e in do_cfunc (c=0xbfffed14, args=0x0, from_tty=1) at
cli/cli-decode.c:57
#11 0x080c356e in cmd_func (cmd=0x83f8c30, args=0x0, from_tty=1) at
cli/cli-decode.c:1627
#12 0x080989ef in execute_command (p=0x83e08e9 "", from_tty=1) at
top.c:733


the session log,

(gdb) b f90demo.f90 : 41
During symbol reading, unsupported tag: 'DW_TAG_module'.
During symbol reading, Attribute value is not a constant
(DW_FORM_block1).
Breakpoint 1 at 0x804b007: file f90demo.f90, line 41.
(gdb) r
Starting program: /home/david/f90demo

Breakpoint 1, sample () at f90demo.f90:86
warning: Source file is more recent than executable.

86      CALL MPI_INIT(ierr)
Current language:  auto; currently fortran
(gdb) watch i
During symbol reading, incomplete CFI data; unspecified registers (e.g.,
eax) at 0x804bc35.
Hardware watchpoint 2: i
(gdb) n
Error in re-setting breakpoint 2:
No symbol "i" in current context.
During symbol reading, incomplete CFI data; unspecified registers (e.g.,
eax) at 0xb7f3b612.
#

I know the patch I originally suggested could be a cure of the symptom,
rather than the cause - but as it's harmless, if we can't figure out why
it happens, it could be worth just committing anyway: all the patch does
is check a value is non-null, and if so takes action - without the patch
such a scenario will always segfault!

Cheers
David

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

[Daniel Jacobowitz]

On Sun, Nov 21, 2004 at 12:25:51AM +0000, David Lecomber wrote:
> > Also, last time we talked, I asked whether this could be due to the
> > Fedora exec-shield feature, but didn't see any response to that.
> > Could you please check that?
> 
> I'm not sure how to verify that one - the seg fault happens running as
> either root or normal user, if that's related..

You can disable it in /proc somewhere.

> Thanks for looking at this bug, here's the latest stack trace and
> session log for current CVS:
> 
> Program received signal SIGSEGV, Segmentation fault.
> evaluate_subexp (expect_type=0x0, exp=0x0, pos=0xbfffed14,
> noside=EVAL_NORMAL) at eval.c:71
> 71        return (*exp->language_defn->la_exp_desc->evaluate_exp)
> (gdb) bt
> #0  evaluate_subexp (expect_type=0x0, exp=0x0, pos=0xbfffed14,
> noside=EVAL_NORMAL) at eval.c:71
> #1  0x080f120d in evaluate_expression (exp=0x0) at eval.c:161
> #2  0x080e159d in insert_bp_location (bpt=0x85208d0,
> tmp_error_stream=0x8493008, disabled_breaks=0xbfffedb0,
>     process_warning=0xbfffedb4, hw_breakpoint_error=0xbfffedb8) at
> breakpoint.c:949

Presumably we went wrong at breakpoint.c:7299.

> (gdb) watch i
> During symbol reading, incomplete CFI data; unspecified registers (e.g.,
> eax) at 0x804bc35.
> Hardware watchpoint 2: i
> (gdb) n
> Error in re-setting breakpoint 2:
> No symbol "i" in current context.
> During symbol reading, incomplete CFI data; unspecified registers (e.g.,
> eax) at 0xb7f3b612.
> #

If we can't reset the breakpoint, it should be disabled, and we
shouldn't be re-inserting it.  If parse_exception throws an error, then
the breakpoint is left enabled but without a valid expression.  That
should be fixed instead; if we can't re-parse it, then probably we
should disable it.  We could mark it disabled before attempting to
re-enable it, or catch the error.

It still won't work right; whatever is causing breakpoints to be reset
will disrupt any local breakpoints, because of the comment at line
7283.  We could do better in the case where the objfile that used to
contain the breakpoint has not been changed.  I don't know what caused
breakpoints to be reset, but it was probably not reloading symbols for
the executable!

-- 
Daniel Jacobowitz

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

[Eli Zaretskii]

> Date: Sat, 20 Nov 2004 19:42:16 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, patches <gdb-patches@sources.redhat.com>
> 
> Presumably we went wrong at breakpoint.c:7299.

I'm not sure I follow: that place frees the expression and its value,
but then proceeds to parse and evaluate it again.  Are you saying that
we threw an error there, and thus left the expression unparsed and/or
unevaluated?

David, can you please see if something went wrong near line 7299 in
breakpoint.c?

> If we can't reset the breakpoint, it should be disabled, and we
> shouldn't be re-inserting it.  If parse_exception throws an error, then
> the breakpoint is left enabled but without a valid expression.  That
> should be fixed instead

I agree.

However, if parse_expression (I take it that parse_exception is a
typo) threw an error near breakpoint.c:7299, then wouldn't it throw
the same exception when invoked again in the patch suggested by David?

> It still won't work right; whatever is causing breakpoints to be reset
> will disrupt any local breakpoints, because of the comment at line
> 7283.  We could do better in the case where the objfile that used to
> contain the breakpoint has not been changed.  I don't know what caused
> breakpoints to be reset, but it was probably not reloading symbols for
> the executable!

David, can you see what caused the watchpoint to be re-set?

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

[Daniel Jacobowitz]

On Sun, Nov 21, 2004 at 07:26:08AM +0200, Eli Zaretskii wrote:
> > Date: Sat, 20 Nov 2004 19:42:16 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Eli Zaretskii <eliz@gnu.org>, patches <gdb-patches@sources.redhat.com>
> > 
> > Presumably we went wrong at breakpoint.c:7299.
> 
> I'm not sure I follow: that place frees the expression and its value,
> but then proceeds to parse and evaluate it again.  Are you saying that
> we threw an error there, and thus left the expression unparsed and/or
> unevaluated?
> 
> David, can you please see if something went wrong near line 7299 in
> breakpoint.c?
> 
> > If we can't reset the breakpoint, it should be disabled, and we
> > shouldn't be re-inserting it.  If parse_exception throws an error, then
> > the breakpoint is left enabled but without a valid expression.  That
> > should be fixed instead
> 
> I agree.
> 
> However, if parse_expression (I take it that parse_exception is a
> typo) threw an error near breakpoint.c:7299, then wouldn't it throw
> the same exception when invoked again in the patch suggested by David?

Oops.  Yes, it's a typo.

Presumably, the difference is the context.  In one we're in the context
of whatever triggered the reload; in the other (by luck?) we're in the
original context, where the local variable "i" is back in scope.  This
is all very fishy; it works right for globals, but the case of handling
a watchpoint on a local variable when resetting breakpoints was never
planned for.

> > It still won't work right; whatever is causing breakpoints to be reset
> > will disrupt any local breakpoints, because of the comment at line
> > 7283.  We could do better in the case where the objfile that used to
> > contain the breakpoint has not been changed.  I don't know what caused
> > breakpoints to be reset, but it was probably not reloading symbols for
> > the executable!
> 
> David, can you see what caused the watchpoint to be re-set?

I'm quite curious about this.  Maybe the Intel compiler is loading a
shared library behind the user's back?

-- 
Daniel Jacobowitz

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

[Eli Zaretskii]

> From: David Lecomber <david@streamline-computing.com>
> Cc: Daniel Jacobowitz <drow@false.org>, patches <gdb-patches@sources.redhat.com>
> Date: Sun, 21 Nov 2004 00:25:51 +0000
> 
> > Also, last time we talked, I asked whether this could be due to the
> > Fedora exec-shield feature, but didn't see any response to that.
> > Could you please check that?
> 
> I'm not sure how to verify that one

There should be a way to switch exec-shield off, but I don't know how.
I meant to ask you to see if switching it off makes the problem go
away.

> Thanks for looking at this bug, here's the latest stack trace and
> session log for current CVS:

Thanks, there seems to be a different problem (or maybe several
problems):

> (gdb) b f90demo.f90 : 41
> During symbol reading, unsupported tag: 'DW_TAG_module'.
> During symbol reading, Attribute value is not a constant
> (DW_FORM_block1).
> [...]
> (gdb) watch i
> During symbol reading, incomplete CFI data; unspecified registers (e.g.,
> eax) at 0x804bc35.

Can someone please explain what do these messages mean, in the context
of the problem at hand, and why didn't David report them in a previous
GDB version?  Did the same problems happen in the older GDB as well,
but were just silently ignored, or are we looking at a completely
different cause for a segfault?

Also, David, I asked you to check why doesn't GDB segfault when it
evaluates the same expression on line 1142, before calling
insert_bp_location.

> I know the patch I originally suggested could be a cure of the symptom,
> rather than the cause - but as it's harmless, if we can't figure out why
> it happens, it could be worth just committing anyway: all the patch does
> is check a value is non-null, and if so takes action - without the patch
> such a scenario will always segfault!

Sorry, I'm reluctant to approve a patch that fixes a problem that we
are unable to understand.  It's not clean.

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

[Daniel Jacobowitz]

On Sun, Nov 21, 2004 at 07:16:19AM +0200, Eli Zaretskii wrote:
> > (gdb) b f90demo.f90 : 41
> > During symbol reading, unsupported tag: 'DW_TAG_module'.
> > During symbol reading, Attribute value is not a constant
> > (DW_FORM_block1).

These are limits of the dwarf2 reader.  They're a problem, but not
related.

> > [...]
> > (gdb) watch i
> > During symbol reading, incomplete CFI data; unspecified registers (e.g.,
> > eax) at 0x804bc35.

I think this should be fixed in HEAD, as of now; if not, we'll have to
look at it again.  Andrew checked in a patch for this recently.

-- 
Daniel Jacobowitz

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

[David Lecomber]

> > > (gdb) watch i
> > > During symbol reading, incomplete CFI data; unspecified registers (e.g.,
> > > eax) at 0x804bc35.
> 
> I think this should be fixed in HEAD, as of now; if not, we'll have to
> look at it again.  Andrew checked in a patch for this recently.

Still happens with a fresh CVS from one minute ago..

d.

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

[Eli Zaretskii]

> From: David Lecomber <david@streamline-computing.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, patches <gdb-patches@sources.redhat.com>
> Date: Sun, 21 Nov 2004 10:37:50 +0000
> 
> 
> > > > (gdb) watch i
> > > > During symbol reading, incomplete CFI data; unspecified registers (e.g.,
> > > > eax) at 0x804bc35.
> > 
> > I think this should be fixed in HEAD, as of now; if not, we'll have to
> > look at it again.  Andrew checked in a patch for this recently.
> 
> Still happens with a fresh CVS from one minute ago..

Btw, I must say that this message is utterly unhelpful to users who,
like myself, are not DWARF-2 gurus: it sounds grave and scary, and yet
conveys no information whatsoever about user-level implications of the
problem, to say nothing about any possible ways to work around it.

In other words, this message should be a textbook example of how _not_
to design user interfaces.

Can we please replace the message text with something more useful and
slightly more self-explanatory?