Trivially, should the main thread in the test be waiting on the three
other threads to complete before exiting?
I think jtreg will try to cleanup once the main thread completes. The
main thread should keep an array of the threads it creates and invoke
join() on each of them before returning from main. We do this all the
time in other areas.
-Chris.
On 10/ 4/11 06:20 AM, David Holmes wrote:
Kelly,
The test is trivial - three threads try to get the locale data. Before
the fix you'd have multiple threads stomping on each other - after the
fix they should now be synchronized in terms of the primary
initialization. But I'd have to check the actual locale code as that is
where the synchronization needs to be.
But again the other error comes from jtreg not from the testcase.
David
On 4/10/2011 7:44 AM, Kelly Ohair wrote:
i have seen a similar bug in my own jprt code where i was accidently
working with HashSet or HashMap objects in two different threads very
strange things like this happened
i dont have the testcase handy to look at but i highly suspect the
testcase
this last failure had nothing to with JPRT, just make&make test
the test/Makefile might run jtreg a little differently but the
testcase should not fail
also it is critical that the test be run on a machine with more than
one processor, it just will not reproduce on a machine without
multiple processors
Sent from my iPhone
On Oct 3, 2011, at 14:25, David Holmes<david.hol...@oracle.com> wrote:
On 4/10/2011 3:53 AM, Naoto Sato wrote:
Discussed in the CR 7027061. Never been able to reproduce outside the
JPRT system, and it's difficult to investigate such issue without
reproducing it.
This error message is coming from jtreg:
ACTION: main -- Error. Error while cleaning up threads after test
REASON: User specified action: run main Bug6989440
so it needs to be investigated by jtreg folk. I suspect however that
it may be related to trying to interrupt the threads due to a timeout.
David
-----
Naoto
On 10/2/11 7:39 PM, Alan Bateman wrote:
I haven't seen it but Olivier Lagneau asked me off-list recently about
the same issue (same test, same failure mode). I've cc'ed the i18n
folks
in case they recognize it. My guess is that this is an implementation
bug in LocaleServiceProviderPool rather than a test bug.
-Alan.
Kelly O'Hair wrote:
Anyone seen this testcase failure before?
-kto
--------------------------------------------------
TEST: java/util/Locale/Bug6989440.java
JDK under test:
(/tmp/jprt/P1/001456.jprtadm/testproduct/solaris_i586_5.10-product)
openjdk version "1.8.0-internal"
OpenJDK Runtime Environment (build
1.8.0-internal-201110030014.jprtadm.jdk-b00)
Java HotSpot(TM) Client VM (build 22.0-b03, mixed mode, sharing)
ACTION: compile -- Passed. Compilation successful
REASON: User specified action: run compile -XDignore.symbol.file=true
Bug6989440.java TIME: 0.053 seconds
messages:
command: compile -XDignore.symbol.file=true
/tmp/jprt/P1/001456.jprtadm/source/test/java/util/Locale/Bug6989440.java
reason: User specified action: run compile -XDignore.symbol.file=true
Bug6989440.java elapsed time (seconds): 0.053
ACTION: build -- Passed. All files up to date
REASON: Named class compiled on demand
TIME: 0.0 seconds
messages:
command: build Bug6989440
reason: Named class compiled on demand
elapsed time (seconds): 0.0
ACTION: main -- Error. Error while cleaning up threads after test
REASON: User specified action: run main Bug6989440 TIME: 120.01
seconds
messages:
command: main Bug6989440
reason: User specified action: run main Bug6989440 elapsed time
(seconds): 120.01
STDOUT:
STDERR:
JavaTest Message: Test complete.
TEST RESULT: Error. Error while cleaning up threads after test
--------------------------------------------------
