RFR(S) 8017498: JVM crashes when native code calls sigaction(sig) where sig>=0x20
Karen Kinnear
karen.kinnear at oracle.com
Tue Jul 9 15:08:47 PDT 2013
Calvin,
The changes look good - thanks for fixing this.
I agree with David - the likelihood of hanging depends on what you
overwrite, so not hanging is good but not sufficient. That said, the
new test is still useful.
thanks,
Karen
On Jul 8, 2013, at 6:57 PM, 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/
>
> 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.
>
> 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