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