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
next prev parent 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).