public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: "Maciej W. Rozycki" <macro@mips.com>
Cc: Djordje Todorovic <djordje.todorovic@rt-rk.com>,
	       Pedro Alves <palves@redhat.com>,
	binutils@sourceware.org,        gdb-patches@sourceware.org,
	asowda@cisco.com,        petar.jovanovic@rt-rk.com,
	nemanja.popov@rt-rk.com,        nikola.prica@rt-rk.com
Subject: Re: [PATCH 3/3] Add test for fetching TLS from core file
Date: Tue, 24 Oct 2017 02:05:00 -0000	[thread overview]
Message-ID: <f18d55bff36f7b579cb9f2dbd95fb401@polymtl.ca> (raw)
In-Reply-To: <alpine.DEB.2.00.1710192123531.3886@tp.orcam.me.uk>

On 2017-10-23 19:42, Maciej W. Rozycki wrote:
>  You can't guarantee overall a test program won't hang, loop, etc. due 
> to
> a bug somewhere.  The issue of lingering processes should IMHO be 
> handled
> by assigning software run on the target a new session and then killing 
> the
> process group on completion.  I believe this is actually done already, 
> as
> this is how expect's `spawn' works and I think we also have it handled 
> for
> the remote case in the `gdbserver' test harness (but I'd love to get a
> confirmation here).
> 
>  How do you propose anyway, in the absence of an infinite wait/loop, to
> ensure that the process does not terminate before the test harness has
> done its processing?

Ah sorry, I saw the while (1) loop in the thread function, and thought 
that the main function waited for the threads to complete.  But it 
doesn't, it would exit right away after creating the threads.

What I meant was to try to avoid infinite loops.  Instead of

   while (1)
     sleep (1);

you can generally do

   for (int i = 0; i < 100; i++)
     sleep (1);

So that if the process runs free, it will eventually exit by itself.

Simon

  reply	other threads:[~2017-10-24  2:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-19 20:14 Simon Marchi
2017-10-23 23:43 ` Maciej W. Rozycki
2017-10-24  2:05   ` Simon Marchi [this message]
  -- strict thread matches above, loose matches on Subject: below --
2017-10-25 14:15 [PATCH 1/3] BFD: Write Linux core PRSTATUS note into MIPS " Djordje Todorovic
2017-10-25 14:15 ` [PATCH 3/3] Add test for fetching TLS from " Djordje Todorovic
2017-10-17 13:50 [PATCH 1/3] BFD: Write Linux core PRSTATUS note into MIPS " Djordje Todorovic
2017-10-17 13:50 ` [PATCH 3/3] Add test for fetching TLS from " Djordje Todorovic
2017-10-18 13:37   ` Maciej W. Rozycki
2017-10-24 11:17     ` 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=f18d55bff36f7b579cb9f2dbd95fb401@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=asowda@cisco.com \
    --cc=binutils@sourceware.org \
    --cc=djordje.todorovic@rt-rk.com \
    --cc=gdb-patches@sourceware.org \
    --cc=macro@mips.com \
    --cc=nemanja.popov@rt-rk.com \
    --cc=nikola.prica@rt-rk.com \
    --cc=palves@redhat.com \
    --cc=petar.jovanovic@rt-rk.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).