RFR(S): JDK-8145317 ReservedStackTest fails with ReentrantLock looks corrupted

[Frederic Parain]

Dan,

Thank you for the review.

The mismatch between the log of the JPRT job and the
webrev is due to a last minute change.
The JPRT job is using a version where a RuntimeException
is thrown when a failure is detected. I changed it
later to throw an Error in order to be more consistent
with other JTREG tests.
I've tried the two versions locally on a Linux/x86
box and the test engine detects failures correctly
in both cases, but I didn't re-start a new JPRT
job after the change.

Fred

On 12/17/2015 10:24 PM, Daniel D. Daugherty wrote:
> Thumbs up on the latest version of the test.
>
> So here's what one of the failures looks like:
>
> Test started execution at frame = 29227
> FAILED: ReentrantLock 163 looks corrupted
> STDERR:
> java.lang.RuntimeException: FAILED: ReentrantLock 163 looks corrupted
>      at ReservedStackTest$RunWithSOEContext.run(ReservedStackTest.java:202)
>      at java.lang.Thread.run(Thread.java:747)
> STATUS:Failed.`main' threw exception: java.lang.RuntimeException:
> FAILED: ReentrantLock 163 looks corrupted
>
> The stack trace snippet is showing one of the worker threads
> throwing an exception which is what I expected.
>
> What I don't understand is that last line:
>
> STATUS:Failed.`main' threw exception: java.lang.RuntimeException:
> FAILED: ReentrantLock 163 looks corrupted
>
> I don't see how the 'main' thread is catching and rethrowing the exception
> from the worker thread. However, failure detection is working and the
> test fails (which is what we wanted in this run).
>
> This is making me wonder if JTREG has a wrapper around the test code that
> catches any exceptions thrown by any of the threads in the test... Don't
> know... but it works and I stand corrected.
>
> Dan
>
>
> On 12/17/15 1:29 PM, Frederic Parain wrote:
>> Here's a new webrev:
>> http://cr.openjdk.java.net/~fparain/8145317/webrev.01/
>>
>> Call to System.exit() has been removed.
>>
>> The new version has been tested with JPRT on all platforms
>> including aarch64.
>>
>> I have another JPRT job running with the feature disabled
>> to check if the failure is detected correctly. So far,
>> it has been successfully detected on MacOSX and Solaris
>> platforms, Linux targets have not been run yet.
>>
>> Thanks,
>>
>> Fred
>>
>> On 17/12/2015 15:10, Christian Tornqvist wrote:
>>> Hi Frederic,
>>>
>>> You're not allowed to do System.exit() in a jtreg test, please change
>>> the test to simply return.
>>>
>>> Thanks,
>>> Christian
>>>
>>> -----Original Message-----
>>> From: hotspot-runtime-dev
>>> [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of
>>> Frederic Parain
>>> Sent: Wednesday, December 16, 2015 7:12 AM
>>> To: hotspot-runtime-dev at openjdk.java.net
>>> Subject: RFR(S): JDK-8145317 ReservedStackTest fails with
>>> ReentrantLock looks corrupted
>>>
>>> Please review this small fix in ReservedStackTest test.
>>> The test didn't exclude correctly some platforms where the feature is
>>> not supported. The logic has been changed to explicitly list the
>>> supported platforms.
>>>
>>> CR: https://bugs.openjdk.java.net/browse/JDK-8145317
>>>
>>> Webrev: http://cr.openjdk.java.net/~fparain/8145317/webrev/
>>>
>>> Tested with JPRT, testset hotspot with aarch64 platform manually
>>> added to the target platforms list.
>>>
>>> Thanks,
>>>
>>> Fred
>>>
>>> --
>>> Frederic Parain - Oracle
>>> Grenoble Engineering Center - France
>>> Phone: +33 4 76 18 81 17
>>> Email: Frederic.Parain at oracle.com
>>>
>>
>

-- 
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com