[Bug 1602] java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java stalls due to segfaults

[bugzilla-daemon at icedtea.classpath.org]

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1602

--- Comment #1 from Raphael Geissert <geissert at debian.org> ---
(In reply to comment #0)
[...]
> 4.7) the LastElement.java test stalls with no special output in the test
> harness.

I'm looking at what other details I can provide, and the first thing I noticed
is that I got the name of the test wrong. According to the tests order, it is
the MultipleProducersSingleConsumerLoops.java test that is triggering the bug.
However, it is the thread that sends "hello world" the one that segfaults (it
appears that the signal is ignored and the code continues retrying) - in which
case it seems like it's java/net/MulticastSocket/SetOutgoingIf.java
I see it calling sendto(..., "hello world", ... ) to an IPv6-mapped v4
multicast address (::ffff:224.1.2.1) on port 9001, followed by another sendto()
with the same parameters except that this time it sends it to ff02::1:2. So, it
appears that it is the Sender thread of the test. Tracing the thread there's
the following:
<a segfault>
[
 a series of futex calls,
 sendto()x2
]x5
<a segfault>

And after a few repetitions of that pattern, it breaks by only calling sendto()
to the ipv4 multicast address, then a series of futex calls (a FUTEX_WAIT which
returns 0, followed by a few FUTEX_WAKE), the segfault, a few more futex calls
(FUTEX_WAIT which returns EAGAIN and a couple of FUTEX_WAKE), the sendto() to
the v6 addr, and a segfault.

When changing the CPU affinity the segfaults stop, yet the thread keeps
running. In fact, the test suite now continues (but notice that the test that
was supposed to be running was
java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java).
So I suspect that the threads are not being collected - there are more than 250
now. A look at the CPU were each thread is, there are quite a few that are
still on a different CPU than the one I chose when setting the affinity.
Tracing one of those threads I see it is stuck in a FUTEX_WAIT with a NULL
timeout.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20131118/9f7edc38/attachment.html