From: "Eli Zaretskii" <eliz@gnu.org>
To: Daniel Jacobowitz <drow@false.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 05:29:00 -0000 [thread overview]
Message-ID: <01c4cf8a$Blat.v2.2.2$c01d5200@zahav.net.il> (raw)
In-Reply-To: <20041121004216.GB26335@nevyn.them.org> (message from Daniel Jacobowitz on Sat, 20 Nov 2004 19:42:16 -0500)
> 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?
next prev parent reply other threads:[~2004-11-21 5:29 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 [this message]
2004-11-21 6:48 ` Daniel Jacobowitz
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='01c4cf8a$Blat.v2.2.2$c01d5200@zahav.net.il' \
--to=eliz@gnu.org \
--cc=david@streamline-computing.com \
--cc=drow@false.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