RFR: 8023720: setjmp/longjmp changes the process signal mask on OS X

David Holmes david.holmes at oracle.com
Tue Aug 27 04:45:59 PDT 2013


On 27/08/2013 9:41 PM, Staffan Larsen wrote:
>
> On 27 aug 2013, at 13:38, David Holmes <David.Holmes at oracle.com> wrote:
>
>> On 27/08/2013 6:48 PM, Staffan Larsen wrote:
>>> I have also made a fix for hotspot. I messed up the link in the last email so here are both webrevs.
>>>
>>> jdk: http://cr.openjdk.java.net/~sla/8023786/webrev.00/
>>
>> Seems okay.
>>
>>> hotspot: http://cr.openjdk.java.net/~sla/8023720/webrev.00/
>>
>> ??? You didn't use _setjmp/_longjmp you just tried to save and restore the current thread's sigmask. Which won't help in general if longjmp just fubar'd the process sigmask. The effect of setting the process sigmask in a multi-threaded process is undefined.
>
> Ah, but in this case we use sigsetjmp/siglongjmp which do not touch the signal mask if sigsetjmp is called with 0 as the second parameter.

Ah! Sorry it's getting late and I missed the sig part. Makes sense now.

Reviewed.

Thanks,
David

> /Staffan
>
>>
>> David
>>
>>
>>> Thanks,
>>> /Staffan
>>>
>>> On 27 aug 2013, at 10:41, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>>>
>>>> The original conversation about this problem is here:  http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-August/011318.html
>>>>
>>>> In short, setjmp/longjmp on OS X messes up the signal mask and we should use _setjmp/_longjmp instead.
>>>>
>>>> This change fixes two occurences in the jdk. There are a couple more in the client and hotspot areas which I will file followup bugs about.
>>>>
>>>> webrev: http://cr.openjdk.java.net/~sla/8023720/webrev.00/
>>>>
>>>> Thanks,
>>>> /Staffan
>>>
>


More information about the hotspot-runtime-dev mailing list