From: compudj@krystal.dyndns.org (Mathieu Desnoyers)
Subject: [ltt-dev] [UST PATCH] Fix the once in a while freeze of the tests
Date: Sun, 20 Feb 2011 10:17:45 -0500 [thread overview]
Message-ID: <BLU0-SMTP64210ABE98921B8359362F96D60@phx.gbl> (raw)
In-Reply-To: <BLU0-SMTP7877677646A5D05A9F129C96D60@phx.gbl>
* Mathieu Desnoyers (compudj at krystal.dyndns.org) wrote:
> * Yannick Brosseau (yannick.brosseau at gmail.com) wrote:
> > Sometimes, the thread in the read function would lock the pipe so the
> > setlinebuf would freeze on it. Set the linebuf before we create the
> > thread to fix this deadlock
>
> Can you update the description to show which locks are involved in this
> deadlock scenario ? E.g.
>
> - CPU A - CPU B
>
> function function
> lock A (taken) lock B (taken)
> lock B (waiting)
> lock A (waiting) <-- deadlock
>
> Or show it with the lock chain dependency analysis. But it's important
> to have this information along with this kind of fix.
Hrm, ok I looked at tap.c, and it's not a deadlock at all: it's rather
that the _tap_comment_stdout thread can start using pipe_r_file when it
is still uninitialized.
I'll update the comment and pull the patch.
Thanks,
Mathieu
>
> Thanks,
>
> Mathieu
> >
> > Signed-off-by: Yannick Brosseau <yannick.brosseau at gmail.com>
> > ---
> > tests/tap.c | 5 ++++-
> > 1 files changed, 4 insertions(+), 1 deletions(-)
> >
> > diff --git a/tests/tap.c b/tests/tap.c
> > index a54fd17..4bb695e 100644
> > --- a/tests/tap.c
> > +++ b/tests/tap.c
> > @@ -58,6 +58,9 @@ static void tap_comment_stdout(void)
> > goto close_pipe;
> > }
> >
> > + /* Set it before we create the reading thread */
> > + setlinebuf(pipe_r_file);
> > +
> > stdout_fileno = fileno(stdout);
> > if (stdout_fileno < 0) {
> > perror("# Couldn't get fileno for stdout!?");
> > @@ -112,7 +115,7 @@ static void tap_comment_stdout(void)
> >
> > setlinebuf(stdout);
> > setlinebuf(stderr);
> > - setlinebuf(pipe_r_file);
> > +
> >
> > return;
> >
> > --
> > 1.7.2.3
> >
> >
> > _______________________________________________
> > ltt-dev mailing list
> > ltt-dev at lists.casi.polymtl.ca
> > http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> >
>
> --
> Mathieu Desnoyers
> Operating System Efficiency R&D Consultant
> EfficiOS Inc.
> http://www.efficios.com
>
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2011-02-20 15:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-18 21:36 Yannick Brosseau
2011-02-20 0:57 ` Mathieu Desnoyers
2011-02-20 15:17 ` Mathieu Desnoyers [this message]
[not found] ` <BLU0-SMTP101D3A13834942CDAF72E4196D60@phx.gbl>
2011-02-20 15:45 ` Yannick Brosseau
2011-02-20 18:40 ` Mathieu Desnoyers
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=BLU0-SMTP64210ABE98921B8359362F96D60@phx.gbl \
--to=compudj@krystal.dyndns.org \
/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