RFR(S) 8017498: JVM crashes when native code calls sigaction(sig) where sig>=0x20

David Holmes david.holmes at oracle.com
Tue Jul 9 18:17:46 PDT 2013


On 9/07/2013 8:57 AM, Calvin Cheung wrote:
> Hi David,
>
> Thanks for your review.
> I've updated the webrev at the same location:
>      http://cr.openjdk.java.net/~ccheung/8017498/webrev/

Thanks Calvin - looks good.

> I've re-run the vm.quick, vm.signal, and regression test on linux_64.
> I've also contacted the original submitter of this bug.

Okay. Once they have (hopefully!) confirmed the fix this will be set to go.

David

> thanks,
> Calvin
>
> On 7/7/2013 6:23 PM, David Holmes wrote:
>> HI Calvin,
>>
>> On 6/07/2013 5:53 AM, Calvin Cheung wrote:
>>> Please review a small fix:
>>> http://cr.openjdk.java.net/~ccheung/8017498/webrev/
>>>
>>> Bug:
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017498
>>> https://jbs.oracle.com/bugs/browse/JDK-8017498
>>>
>>> Summary:
>>> I couldn't reproduce the crash as stated in the bug report.
>>> However, I saw hang in the native code when sig value is much
>>> greater than 32, e.g. 132. Fix suggested by David H. is to add
>>> another check for the sig value is less than MAXSIGNUM in jsig.c.
>>
>> I don't think this is quite enough. I think the second clause:
>>
>> 119   } else if (jvm_signal_installing) {
>>
>> would also need to be
>>
>> 119   } else if (sig < MAXSIGNUM && jvm_signal_installing) {
>>
>>> With the fix, the hang is gone and the regression test is for
>>> testing the hang condition.
>>
>> We need to reach out to the original reporter and ensure that this
>> fixes their problem.
>>
>> Thanks,
>> David
>>
>>> Testing:
>>> JPRT
>>> jtreg test on test/runtime with the new regression test
>>> Aurora adhoc vm.signal and vm.quick tests on linux
>>>      (in progress, no failure so far)
>>>
>>> thanks,
>>> Calvin
>


More information about the hotspot-runtime-dev mailing list