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

Daniel Jacobowitz
2004-11-21T06:48:21Z

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