RFR(XXS): 8032518: fatal error has been detected by the Java Runtime Environment (access violation)

[David Holmes]

Still good.

On 30/01/2014 11:52 PM, Markus Gronlund wrote:
> Thanks guys.
>
> Yes, the reason I added the return in 37 is to avoid anyone adding anything after the else clause moving forward. However, as Dmitry pointed out, an inversion of the version check will make this clearer - thanks.

Given the death of hsx the version check seems removable altogether ;-)

Cheers,
David


> In addition, just realized I hadn't pulled in the latest changes for the last webrev (for the diff), there were actually recent updates to this file as of:
>
> changeset:   9197:902aa2b3265c
> user:        simonis
> date:        Mon Jan 20 17:16:05 2014 +0100
> summary:     8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests
>
>
> So here's an updated webrev for your convenience:
>
> http://cr.openjdk.java.net/~mgronlun/8032518/webrev02/
>
> Dmitry:
>
> With the pull, the locations of "free, throw, return" reduces to only two so I don't think refactoring here will add much. Thanks for pointing it out though.
>
> Cheers
> Markus
>
>
> -----Original Message-----
> From: David Holmes
> Sent: den 30 januari 2014 13:06
> To: Markus Gronlund; serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-runtime-dev
> Subject: Re: RFR(XXS): 8032518: fatal error has been detected by the Java Runtime Environment (access violation)
>
> This is good to me. The return at line 37 was unnecessary but it does help reinforce the pattern that you must return after JNU_ThrowXXX
>
> David
>
> On 30/01/2014 9:11 PM, Markus Gronlund wrote:
>> Greetings,
>>
>> Kindly asking for reviews for this very small fix:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8032518
>>
>> Webrev: http://cr.openjdk.java.net/~mgronlun/8032518/webrev01/
>>
>> Background:
>>
>> Still a bit puzzled about the manifestations of the crashes when
>> inspecting the .mdmp files, which seems to be dereferencing a (debug)
>> ResourceObj allocation[0] cookie address (~allocation address) at
>> point of crashing. In addition, if the issue is an effect of not
>> handling OOM correctly, I would expect to see a _pending_exception off
>> the problematic thread, but there seems to be none. Also unknown why
>> this seems to occur more on Windows x64 than any other platform.
>>
>> Testing:
>>
>> I have iterated the testcase nsk/stress/jck60/jck60014 locally -
>> without suggested fixes I get about 10 crashes in about 300 runs. With
>> fixes I am yet to see any crashes, currently ~600 iterations.
>>
>> I suggest to putback this first (since it should be fixed anyhow), to
>> see the effect, before any more time is spent on tracing this down.
>>
>> Thanks
>>
>> Markus
>>