From: paul@linuxaudiosystems.com
To: "Lee Revell" <rlrevell@joe-job.com>
Cc: "Jakub Jelinek" <jakub@redhat.com>,
"Andrew Morton" <akpm@osdl.org>,
"Jamie Lokier" <jamie@shareable.org>,
linux-kernel@vger.kernel.org, mingo@elte.hu,
"Chris Morgan" <cmorgan@alum.wpi.edu>,
paul@linuxaudiosystems.com, seto.hidetoshi@jp.fujitsu.com
Subject: Re: kernel bug: futex_wait hang
Date: Wed, 23 Mar 2005 05:12:59 -0800 (PST) [thread overview]
Message-ID: <3726.71.100.26.22.1111583579.spork@webmail.linuxaudiosystems.com> (raw)
In-Reply-To: <1111535887.4691.26.camel@mindpipe>
> Paul is on vacation for a week so I suspect this will have to wait for
> his return. But he's been right about similar issues in the past so I'm
> inclined to believe him.
>
> In the meantime if anyone cares to investigate, the problem is trivial
> to reproduce. All you need is JACK, XMMS, xmms-jack and any 2.6 kernel.
fortunately (or perhaps not), by the powers of webmail, here i am to just
mention a couple more details for anyone who cares to think about this.
the hang occurs during an attempted thread cancel+join. we know from
strace that one thread calls tgkill() on the other. the other thread is
blocked in a poll call on a FIFO. after tgkill, the first thread enters a
futex wait, apparently waiting for the thread ID of the cancelled thread
to appear at some location (just a guess based on the info from strace).
the wait never returns, and so the first thread ends up hung in
pthread_join(). there are no user-defined mutexes or condvars involved.
what is rather odd is that when we have checked for the persistence (or
otherwise) of the cancelled thread, it appears as if several other threads
have died, not just the cancelled one. the primary tester was unclear if
this was to be expected or not (chris morgan, the author of xmms-jack),
and i cannot say definitively whether or not we know for certain that the
cancelled thread no longer exists.
as lee mentioned, i am on vacation right now, using some xp machine at a
relative's house, so i can't test anything till i return.
next prev parent reply other threads:[~2005-03-23 13:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-22 3:59 Lee Revell
2005-03-22 4:20 ` Andrew Morton
2005-03-22 4:25 ` Lee Revell
2005-03-22 4:46 ` Jamie Lokier
2005-03-22 4:48 ` Jamie Lokier
2005-03-22 5:08 ` Andrew Morton
2005-03-22 5:30 ` Lee Revell
2005-03-22 6:34 ` Jakub Jelinek
2005-03-22 23:58 ` Lee Revell
2005-03-23 13:12 ` paul [this message]
2005-03-23 13:43 ` Jakub Jelinek
2005-03-22 5:15 ` Lee Revell
2005-03-22 15:30 ` Jamie Lokier
2005-03-22 23:18 ` Lee Revell
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=3726.71.100.26.22.1111583579.spork@webmail.linuxaudiosystems.com \
--to=paul@linuxaudiosystems.com \
--cc=akpm@osdl.org \
--cc=cmorgan@alum.wpi.edu \
--cc=jakub@redhat.com \
--cc=jamie@shareable.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rlrevell@joe-job.com \
--cc=seto.hidetoshi@jp.fujitsu.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
Powered by JetHome