Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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