From: Daniel Jacobowitz <drow@false.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: david@streamline-computing.com, gdb-patches@sources.redhat.com
Subject: Re: [PATCH] Seg fault whilst stepping when watch set [ping!] [in breakpoint.c]
Date: Sun, 21 Nov 2004 06:48:00 -0000 [thread overview]
Message-ID: <20041121064812.GA909@nevyn.them.org> (raw)
In-Reply-To: <01c4cf8a$Blat.v2.2.2$c01d5200@zahav.net.il>
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
next prev parent reply other threads:[~2004-11-21 6:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <01c4cef8$Blat.v2.2.2$3fd12960@zahav.net.il>
2004-11-21 0:24 ` David Lecomber
2004-11-21 0:42 ` Daniel Jacobowitz
2004-11-21 5:29 ` Eli Zaretskii
2004-11-21 6:48 ` Daniel Jacobowitz [this message]
2004-11-21 5:19 ` Eli Zaretskii
2004-11-21 6:49 ` Daniel Jacobowitz
2004-11-21 10:36 ` David Lecomber
2004-11-21 19:40 ` Eli Zaretskii
2004-10-17 0:09 [PATCH] Seg fault whilst stepping when watch set David Lecomber
2004-10-25 16:10 ` [PATCH] Seg fault whilst stepping when watch set [ping!] David Lecomber
2004-11-01 22:05 ` [PATCH] Seg fault whilst stepping when watch set [ping!] [in breakpoint.c] David Lecomber
2004-11-02 4:38 ` Eli Zaretskii
[not found] ` <1099385491.31287.19.camel@cpc1-oxfd5-5-0-cust86.oxfd.cable.ntl.com>
2004-11-02 21:40 ` Eli Zaretskii
2004-11-03 12:08 ` David Lecomber
2004-11-17 21:38 ` David Lecomber
2004-11-03 18:09 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041121064812.GA909@nevyn.them.org \
--to=drow@false.org \
--cc=david@streamline-computing.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox