From: "Pierre Muller" <muller@ics.u-strasbg.fr>
To: "'Pedro Alves'" <pedro@codesourcery.com>
Cc: "'Joel Brobecker'" <brobecker@adacore.com>, <gdb-patches@sourceware.org>
Subject: RE: [BUG] Quit and "(running)" problem
Date: Fri, 16 Jan 2009 15:39:00 -0000 [thread overview]
Message-ID: <007101c977f0$8efcd340$acf679c0$@u-strasbg.fr> (raw)
In-Reply-To: <200901161513.10684.pedro@codesourcery.com>
Thanks for the explanations...
By the way, this also explains why I
got troubles when I tried some code
with windows OS, where I added some
debug informations using printf_unfiltered into the windows
function that handles console control events.
The problem was that even printf_unfiltered
adds some cleanups, but this control function
is executed in a newly created thread, which
leads to big troubles, if a second control event
is generated...
Pierre Muller
Pascal language support maintainer for GDB
> -----Message d'origine-----
> De : Pedro Alves [mailto:pedro@codesourcery.com]
> Envoyé : Friday, January 16, 2009 4:13 PM
> À : Pierre Muller
> Cc : 'Joel Brobecker'; gdb-patches@sourceware.org
> Objet : Re: [BUG] Quit and "(running)" problem
>
> A Friday 16 January 2009 08:54:21, Pierre Muller wrote:
> > I can confirm that your patch fixed the simple
> > test case that I submitted in PR9747.
>
> Thank you.
>
> > Reading the patch, I was wondering about the
> > utility of the old_chain cleanup in fetch_inferior_event
> > function. But this is probably due to my
> > lack of comprehension of the cleanup chain mechanisms.
> >
> > Is it really possible to reach
> > do_cleanups (old_chain)
> > with something else that old_chain
> > as the top item on the cleanup list?
>
> Yes, there's a make_cleanup_restore_current_thread call
> there that adds a new cleanup to the chain.
>
> > I thought that all the cleanups where stored
> > as local variables, so that all cleanups
> > that were set in functions called while running any
> > code called from within the fetch_inferior_event
> > would be invalid data anyhow at that point,
> > as the stack might have been overwritten by calls to other functions.
>
> Some confusion here. Instead of trying to explain the basic mechanism
> and doing a lousy job at it, I suggest taking a look at the Cleanups
> section
> in internals manual, if you haven't already, which I think explains
> it quite nicelly:
>
> http://sourceware.org/gdb/current/onlinedocs/gdbint_15.html#SEC118
>
> Another way to really understand cleanups is to step through
> the make_cleanup, do_cleanups and discard_cleanups functions, it looks
> scarrier than it is.
>
>
> In this particular case, we have:
>
> old_chain +----+- <null_cleanup>
> |
> +- <restore_current_thread> (always run this, wether
> leaving with an exception or leaving succesfully)
> |
> ts_old_chain +-+- <finish_thread_state> (only run if there's an
> exception)
>
> [do something that can throw]
>
> [ if we got pass it sucessfully, discard the
> <finish_thread_state> cleanup chain ]
>
> /* No error, don't finish the thread states yet. */
> discard_cleanups (ts_old_chain);
>
> So, at this point we have something like:
>
> old_chain +----+- <null_cleanup>
> |
> +- <restore_current_thread> (always run this, wether
> leaving with an exception or leaving succesfully)
>
> ts_old_chain (invalid, dangling pointer)
>
> /* Revert thread and frame. */
> do_cleanups (old_chain);
>
> This statement runs the <restore_current_thread>
> cleanup.
>
> ( I mentioned doing a lousy job explaining it. )
>
> --
> Pedro Alves
next prev parent reply other threads:[~2009-01-16 15:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-15 12:40 Pierre Muller
2009-01-15 13:59 ` Joel Brobecker
2009-01-15 16:03 ` Pierre Muller
2009-01-15 22:15 ` Pedro Alves
2009-01-16 8:55 ` Pierre Muller
2009-01-16 15:13 ` Pedro Alves
2009-01-16 15:39 ` Pierre Muller [this message]
2009-01-15 14:42 ` Pedro Alves
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='007101c977f0$8efcd340$acf679c0$@u-strasbg.fr' \
--to=muller@ics.u-strasbg.fr \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=pedro@codesourcery.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