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

[Daniel Jacobowitz <drow at false dot org>]

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