From: Daniel Jacobowitz <drow@false.org>
To: Dave Allan <da_gdb@egenera.com>
Cc: gdb@sources.redhat.com
Subject: Re: execute_control_command may not remove its cleanups
Date: Thu, 19 Feb 2004 15:40:00 -0000 [thread overview]
Message-ID: <20040219154016.GA24829@nevyn.them.org> (raw)
In-Reply-To: <1077204518.1305.1192.camel@hasufel.egenera.com>
On Thu, Feb 19, 2004 at 10:28:38AM -0500, Dave Allan wrote:
> Hello,
>
> I ran into a reproducible segfault in gdb (v.5.3, but the offending code
> is still present in the CVS tree I checked out this morning). I traced
> the problemto the execute_control_command function in cli/cli-script.c.
>
> It appears that execute_control_command doesn't always do or discard the
> cleanups it creates before returning, which is not right according to
> the gdb internals docs. According to section 13.1 Cleanups, "Your
> function should explicitly do or discard the cleanups it creates.
> Failing to do this leads to non-deterministic behavior..."
>
> The problem is that the call to do_cleanups in execute_control_command
> is conditional (cli/cli-script.c at line 430):
>
> if (old_chain)
> do_cleanups (old_chain);
>
> So, if the cleanup_chain was null entering execute_control_command, then
> old_chain will be null, and the call to do_cleanups doesn't happen.
>
> Removing the if statement, thus making the do_cleanups (old_chain)
> unconditional eliminates the segfault.
>
> Unfortunately, the segfault occurred while I was using gdb run under the
> "crash" kernel dump analysis tool, and it appears to me that under
> normal gdb usage, cleanup_chain is never null going into
> execute_control_command. Thus, do_cleanups is always executed and the
> segfault never appears and I don't have a reproducible test case that
> works against a vanilla build.
>
> However, it seems from code inspection and the gdb internals
> documentation that the call to do_cleanups ought to be unconditional.
> Does that seem right?
No, instead, the cleanup chain should always have an item on it. If
make_cleanup is not called then old_chain will remain NULL, and
do_cleanups (NULL) means "do all cleanups", not "do nothing". It looks
to me like command_handler is responsible for there always being a
cleanup on the chain:
old_chain = make_cleanup (null_cleanup, 0);
but maybe I'm mistaken about that; it's a bit far down the tree.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2004-02-19 15:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-19 15:32 Dave Allan
2004-02-19 15:40 ` Daniel Jacobowitz [this message]
2004-02-19 18:26 ` Dave Allan
2004-02-19 18:47 ` Daniel Jacobowitz
2004-02-19 19:14 ` Dave Allan
2004-02-19 22:19 ` Andrew Cagney
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=20040219154016.GA24829@nevyn.them.org \
--to=drow@false.org \
--cc=da_gdb@egenera.com \
--cc=gdb@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