RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0

Gerard Ziemski-2
On Mac ARM hardware running x86 JDK under Rosetta emulation, a div by 0 instruction causes the VM to crash.

The proposed fix (a workaround) for hotspot is to add **FPE_FLTINV** to the signal handler.

The actual fix needs to be done in macOS by Apple as the expected signal type here is **FPE_FLTDIV**
This issue has been filed with Apple and they are tracking it.

-------------

Commit messages:
 - add FPE_FLTINV to div by 0 signal handler

Changes: https://git.openjdk.java.net/jdk/pull/2615/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2615&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261397
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2615.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2615/head:pull/2615

PR: https://git.openjdk.java.net/jdk/pull/2615
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 [v2]

Gerard Ziemski-2
> On Mac ARM hardware running x86 JDK under Rosetta emulation, a div by 0 instruction causes the VM to crash.
>
> The proposed fix (a workaround) for hotspot is to add **FPE_FLTINV** to the signal handler.
>
> The actual fix needs to be done in macOS by Apple as the expected signal type here is **FPE_FLTDIV**
> This issue has been filed with Apple and they are tracking it.

Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:

  apply new check to macOS only

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2615/files
  - new: https://git.openjdk.java.net/jdk/pull/2615/files/86153738..0b815511

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2615&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2615&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2615.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2615/head:pull/2615

PR: https://git.openjdk.java.net/jdk/pull/2615
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0

Gerard Ziemski-2
In reply to this post by Gerard Ziemski-2
On Wed, 17 Feb 2021 19:06:45 GMT, Gerard Ziemski <[hidden email]> wrote:

> On Mac ARM hardware running x86 JDK under Rosetta emulation, a div by 0 instruction causes the VM to crash.
>
> The proposed fix (a workaround) for hotspot is to add **FPE_FLTINV** to the signal handler.
>
> The actual fix needs to be done in macOS by Apple as the expected signal type here is **FPE_FLTDIV**
> This issue has been filed with Apple and they are tracking it.

Simple native test case for those curious to try it out for themselves:

/*
 Natively on x86_64 we get:
   sigHandler caught sig: 8, info->si_code: 7 [FPE_INTDIV]
 Under Rossetta on M1 for x86_64 binary we get:
   sigHandler caught sig: 8, info->si_code: 5 [FPE_FLTINV]
 */
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
static void sigHandler(int sig, siginfo_t* info, void* arg) {
  printf("sigHandler caught sig: %d, info->si_code: %d [", sig, info->si_code);
  switch (info->si_code) {
    case FPE_FLTDIV: printf("FPE_FLTDIV");break;
    case FPE_INTDIV: printf("FPE_INTDIV");break;
    case FPE_FLTINV: printf("FPE_FLTINV");break;
    default: printf("???");
  }
  printf("]\n");
  exit(sig);
}
int main(int argc, const char * argv[]) {
  struct sigaction sa;
  sigemptyset(&sa.sa_mask);
  sa.sa_sigaction = sigHandler;
  sa.sa_flags = SA_SIGINFO|SA_RESETHAND;
  sigaction(SIGFPE, &sa, NULL);
  volatile int i = 0;
  volatile int j = 47 / i;
  return j;
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/2615
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 [v2]

Thomas Stuefe
In reply to this post by Gerard Ziemski-2
On Wed, 17 Feb 2021 19:25:59 GMT, Gerard Ziemski <[hidden email]> wrote:

>> On Mac ARM hardware running x86 JDK under Rosetta emulation, a div by 0 instruction causes the VM to crash.
>>
>> The proposed fix (a workaround) for hotspot is to add **FPE_FLTINV** to the signal handler.
>>
>> The actual fix needs to be done in macOS by Apple as the expected signal type here is **FPE_FLTDIV**
>> This issue has been filed with Apple and they are tracking it.
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
>
>   apply new check to macOS only

Seems reasonable. Remark below. Looks good otherwise.

Cheers, Thomas

src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp line 475:

> 473: #ifdef AMD64
> 474:       if (sig == SIGFPE  &&
> 475:           (info->si_code == FPE_INTDIV || info->si_code == FPE_FLTDIV MACOS_ONLY(|| info->si_code == FPE_FLTINV))) {

Can you add a comment stating that MacOs (or Rosetta?) misreports FLTDIV as FLTINV?

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2615
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 [v2]

Gerard Ziemski-2
On Wed, 17 Feb 2021 19:39:58 GMT, Thomas Stuefe <[hidden email]> wrote:

>> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
>>
>>   apply new check to macOS only
>
> src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp line 475:
>
>> 473: #ifdef AMD64
>> 474:       if (sig == SIGFPE  &&
>> 475:           (info->si_code == FPE_INTDIV || info->si_code == FPE_FLTDIV MACOS_ONLY(|| info->si_code == FPE_FLTINV))) {
>
> Can you add a comment stating that MacOs (or Rosetta?) misreports FLTDIV as FLTINV?

Will do.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2615
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 [v3]

Gerard Ziemski-2
In reply to this post by Gerard Ziemski-2
> On Mac ARM hardware running x86 JDK under Rosetta emulation, a div by 0 instruction causes the VM to crash.
>
> The proposed fix (a workaround) for hotspot is to add **FPE_FLTINV** to the signal handler.
>
> The actual fix needs to be done in macOS by Apple as the expected signal type here is **FPE_FLTDIV**
> This issue has been filed with Apple and they are tracking it.

Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:

  add comment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2615/files
  - new: https://git.openjdk.java.net/jdk/pull/2615/files/0b815511..8291664e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2615&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2615&range=01-02

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2615.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2615/head:pull/2615

PR: https://git.openjdk.java.net/jdk/pull/2615
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 [v3]

Phil Race
On Wed, 17 Feb 2021 20:01:53 GMT, Gerard Ziemski <[hidden email]> wrote:

>> On Mac ARM hardware running x86 JDK under Rosetta emulation, a div by 0 instruction causes the VM to crash.
>>
>> The proposed fix (a workaround) for hotspot is to add **FPE_FLTINV** to the signal handler.
>>
>> The actual fix needs to be done in macOS by Apple as the expected signal type here is **FPE_FLTDIV**
>> This issue has been filed with Apple and they are tracking it.
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
>
>   add comment

Looks reasonable to me. I suppose there is a BSD unix port that uses this code hence the MACOS_ONLY ?

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2615
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 [v3]

Gerard Ziemski-2
On Wed, 17 Feb 2021 20:39:47 GMT, Phil Race <[hidden email]> wrote:

> Looks reasonable to me. I suppose there is a BSD unix port that uses this code hence the MACOS_ONLY ?

Exactly, any BSD platform uses this implementation. macOS is just one of them.

Thanks Phil!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2615
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 [v2]

Daniel D.Daugherty
In reply to this post by Gerard Ziemski-2
On Wed, 17 Feb 2021 19:52:47 GMT, Gerard Ziemski <[hidden email]> wrote:

>> src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp line 475:
>>
>>> 473: #ifdef AMD64
>>> 474:       if (sig == SIGFPE  &&
>>> 475:           (info->si_code == FPE_INTDIV || info->si_code == FPE_FLTDIV MACOS_ONLY(|| info->si_code == FPE_FLTINV))) {
>>
>> Can you add a comment stating that MacOs (or Rosetta?) misreports FLTDIV as FLTINV?
>
> Will do.

nit - can you put a period at the end of L475.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2615
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 [v3]

Daniel D.Daugherty
In reply to this post by Gerard Ziemski-2
On Wed, 17 Feb 2021 20:01:53 GMT, Gerard Ziemski <[hidden email]> wrote:

>> On Mac ARM hardware running x86 JDK under Rosetta emulation, a div by 0 instruction causes the VM to crash.
>>
>> The proposed fix (a workaround) for hotspot is to add **FPE_FLTINV** to the signal handler.
>>
>> The actual fix needs to be done in macOS by Apple as the expected signal type here is **FPE_FLTDIV**
>> This issue has been filed with Apple and they are tracking it.
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
>
>   add comment

Thumbs up. Nice job on keeping the work around very focused.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2615
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 [v3]

Gerard Ziemski-2
On Wed, 17 Feb 2021 21:53:15 GMT, Daniel D. Daugherty <[hidden email]> wrote:

> Thumbs up. Nice job on keeping the work around very focused.

Thank you Dan!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2615
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 [v3]

David Holmes-2
In reply to this post by Gerard Ziemski-2
On Wed, 17 Feb 2021 20:01:53 GMT, Gerard Ziemski <[hidden email]> wrote:

>> On Mac ARM hardware running x86 JDK under Rosetta emulation, a div by 0 instruction causes the VM to crash.
>>
>> The proposed fix (a workaround) for hotspot is to add **FPE_FLTINV** to the signal handler.
>>
>> The actual fix needs to be done in macOS by Apple as the expected signal type here is **FPE_FLTDIV**
>> This issue has been filed with Apple and they are tracking it.
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
>
>   add comment

Hi Gerard,

I'm concerned by the general problem of encountering new bugs because we are running on an x64 emulation mode on ARM! Is there any way to detect this Rosetta environment? Is there a way to know from the hs_err file (we don't have one for this issue yet) that we executed under Rosetta?

How will we track this bug on Apple's side, such that we can eventually remove this workaround?

The workaround itself seems okay as far as it goes but what happens if native code triggers a real FPE_FLTINV that we will now treat as "div by zero"?

Thanks,
David

-------------

PR: https://git.openjdk.java.net/jdk/pull/2615
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 [v3]

Gerard Ziemski-2
On Thu, 18 Feb 2021 02:28:20 GMT, David Holmes <[hidden email]> wrote:

> Hi Gerard,
>
> I'm concerned by the general problem of encountering new bugs because we are running on an x64 emulation mode on ARM! Is there any way to detect this Rosetta environment?

We can detect if we are running under emulation using this code provided by Apple [https://developer.apple.com/documentation/apple_silicon/about_the_rosetta_translation_environment](https://developer.apple.com/documentation/apple_silicon/about_the_rosetta_translation_environment?language=objc#3616845)

> Is there a way to know from the hs_err file (we don't have one for this issue yet) that we executed under Rosetta?

One can infer such scenario by looking at the log under the _system_ section:

`OS:uname: Darwin 20.3.0 Darwin Kernel Version 20.3.0: Thu Jan 21 00:06:51 PST 2021; root:xnu-7195.81.3~1/RELEASE_ARM64_T8101 x86_64`

We see **RELEASE_ARM64_T8101** type kernel running **x86_64** code, but we should detect this and report it to users directly. Filed a followup issue [JDK-8261966](https://bugs.openjdk.java.net/browse/JDK-8261966) to track it. Thank you for the bringing this point up!

> How will we track this bug on Apple's side, such that we can eventually remove this workaround?

I have filed the issue a while ago with Apple here [https://feedbackassistant.apple.com/feedback/8984455](https://feedbackassistant.apple.com/feedback/8984455), but please note that you probably need Mac developer account to be able to see it.

Apple has set the resolution of this issue as `Potential fix identified - For a future OS update`, but we will always need it for the already released macOS version.

> The workaround itself seems okay as far as it goes but what happens if native code triggers a real FPE_FLTINV that we will now treat as "div by zero"?

Excellent question. According to https://en.wikipedia.org/wiki/IEEE_754 invalid operation is `mathematically undefined, e.g., the square root of a negative number. By default, returns qNaN.` I will test this scenario out and report back...

Regardless though, we absolutely need this workaround for the time being, though we might want to use only in emulation environment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2615
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 [v3]

Gerard Ziemski-2
On Thu, 18 Feb 2021 16:28:38 GMT, Gerard Ziemski <[hidden email]> wrote:

> > The workaround itself seems okay as far as it goes but what happens if native code triggers a real FPE_FLTINV that we will now treat as "div by zero"?
>
> Excellent question. According to https://en.wikipedia.org/wiki/IEEE_754 invalid operation is `mathematically undefined, e.g., the square root of a negative number. By default, returns qNaN.` I will test this scenario out and report back...

According to the **man pages** for `log()` function:

`log(x), log2(x), and log10(x) return a NaN and raise the "invalid" floating-point exception for x < 0.`

and the **man pages** for `sqrt()` function:

`sqrt(x) returns a NaN and generates a domain error for x < 0`

but what I see in our signal handler is a signal of type `FPE_FLTDIV` returned **not** `FPE_FLTINV` for `sqrt(-1.0)` and `log(-1.0)`

I can't seem to be able to get `FPE_FLTINV` at all - it's seems that it's unused natively on `macOS x86_64` so we are good I think.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2615
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 [v3]

David Holmes
Hi Gerard,

On 19/02/2021 5:02 am, Gerard Ziemski wrote:

> On Thu, 18 Feb 2021 16:28:38 GMT, Gerard Ziemski <[hidden email]> wrote:
>
>>> The workaround itself seems okay as far as it goes but what happens if native code triggers a real FPE_FLTINV that we will now treat as "div by zero"?
>>
>> Excellent question. According to https://en.wikipedia.org/wiki/IEEE_754 invalid operation is `mathematically undefined, e.g., the square root of a negative number. By default, returns qNaN.` I will test this scenario out and report back...
>
> According to the **man pages** for `log()` function:
>
> `log(x), log2(x), and log10(x) return a NaN and raise the "invalid" floating-point exception for x < 0.`
>
> and the **man pages** for `sqrt()` function:
>
> `sqrt(x) returns a NaN and generates a domain error for x < 0`
>
> but what I see in our signal handler is a signal of type `FPE_FLTDIV` returned **not** `FPE_FLTINV` for `sqrt(-1.0)` and `log(-1.0)`

Thanks for the further investigation here.

Possibly more bugs in FP handling. :(

Though I'm unclear how to actually trigger SIGFPE in these cases - don't
we have to enable traps at the CPU level via the FPU control word? I
placed this in os::init_2() on Linux:

double d = ::sqrt(-1.0);
printf("%f\n", d);

and it just prints "-nan" with no signal generated.

> I can't seem to be able to get `FPE_FLTINV` at all - it's seems that it's unused natively on `macOS x86_64` so we are good I think.

Ok, but I think we should fix JDK-8261966 and include
VM_Version::is_cpu_emulated() so that we use it to gate the workaround
at runtime. That at least minimises the exposure to the environments
that actually need the workaround.

Thanks,
David



> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/2615
>
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 [v4]

Gerard Ziemski-2
In reply to this post by Gerard Ziemski-2
> On Mac ARM hardware running x86 JDK under Rosetta emulation, a div by 0 instruction causes the VM to crash.
>
> The proposed fix (a workaround) for hotspot is to add **FPE_FLTINV** to the signal handler.
>
> The actual fix needs to be done in macOS by Apple as the expected signal type here is **FPE_FLTDIV**
> This issue has been filed with Apple and they are tracking it.

Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:

  check whether the process is translated

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2615/files
  - new: https://git.openjdk.java.net/jdk/pull/2615/files/8291664e..65dd76da

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2615&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2615&range=02-03

  Stats: 33 lines in 4 files changed: 30 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2615.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2615/head:pull/2615

PR: https://git.openjdk.java.net/jdk/pull/2615
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 [v3]

Gerard Ziemski-2
In reply to this post by Gerard Ziemski-2
On Thu, 18 Feb 2021 18:59:51 GMT, Gerard Ziemski <[hidden email]> wrote:

>>> Hi Gerard,
>>>
>>> I'm concerned by the general problem of encountering new bugs because we are running on an x64 emulation mode on ARM! Is there any way to detect this Rosetta environment?
>>
>> We can detect if we are running under emulation using this code provided by Apple [https://developer.apple.com/documentation/apple_silicon/about_the_rosetta_translation_environment](https://developer.apple.com/documentation/apple_silicon/about_the_rosetta_translation_environment?language=objc#3616845)
>>
>>> Is there a way to know from the hs_err file (we don't have one for this issue yet) that we executed under Rosetta?
>>
>> One can infer such scenario by looking at the log under the _system_ section:
>>
>> `OS:uname: Darwin 20.3.0 Darwin Kernel Version 20.3.0: Thu Jan 21 00:06:51 PST 2021; root:xnu-7195.81.3~1/RELEASE_ARM64_T8101 x86_64`
>>
>> We see **RELEASE_ARM64_T8101** type kernel running **x86_64** code, but we should detect this and report it to users directly. Filed a followup issue [JDK-8261966](https://bugs.openjdk.java.net/browse/JDK-8261966) to track it. Thank you for the bringing this point up!
>>
>>> How will we track this bug on Apple's side, such that we can eventually remove this workaround?
>>
>> I have filed the issue a while ago with Apple here [https://feedbackassistant.apple.com/feedback/8984455](https://feedbackassistant.apple.com/feedback/8984455), but please note that you probably need Mac developer account to be able to see it.
>>
>> Apple has set the resolution of this issue as `Potential fix identified - For a future OS update`, but we will always need it for the already released macOS version.
>>
>>> The workaround itself seems okay as far as it goes but what happens if native code triggers a real FPE_FLTINV that we will now treat as "div by zero"?
>>
>> Excellent question. According to https://en.wikipedia.org/wiki/IEEE_754 invalid operation is `mathematically undefined, e.g., the square root of a negative number. By default, returns qNaN.` I will test this scenario out and report back...
>>
>> Regardless though, we absolutely need this workaround for the time being, though we might want to use only in emulation environment.
>
>> > The workaround itself seems okay as far as it goes but what happens if native code triggers a real FPE_FLTINV that we will now treat as "div by zero"?
>>
>> Excellent question. According to https://en.wikipedia.org/wiki/IEEE_754 invalid operation is `mathematically undefined, e.g., the square root of a negative number. By default, returns qNaN.` I will test this scenario out and report back...
>
> According to the **man pages** for `log()` function:
>
> `log(x), log2(x), and log10(x) return a NaN and raise the "invalid" floating-point exception for x < 0.`
>
> and the **man pages** for `sqrt()` function:
>
> `sqrt(x) returns a NaN and generates a domain error for x < 0`
>
> but what I see in our signal handler is a signal of type `FPE_FLTDIV` returned **not** `FPE_FLTINV` for `sqrt(-1.0)` and `log(-1.0)`
>
> I can't seem to be able to get `FPE_FLTINV` at all - it's seems that it's unused natively on `macOS x86_64` so we are good I think.

> > I can't seem to be able to get `FPE_FLTINV` at all - it's seems that it's unused natively on `macOS x86_64` so we are good I think.
>
> Ok, but I think we should fix JDK-8261966 and include
> VM_Version::is_cpu_emulated() so that we use it to gate the workaround
> at runtime. That at least minimises the exposure to the environments
> that actually need the workaround.

I added the check in this fix - I don't think we should get this issue blocked by JDK-8261966

For JDK-8261966 we can further optimize the check to cache the results, if needed, and we can have a non rushed discussion on how exactly we want the API named (ex. I would prefer to follow Apple's usage and name it is_process_translated()) and how exactly we want it to look in the hs_err log files.


cheers

-------------

PR: https://git.openjdk.java.net/jdk/pull/2615
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 [v4]

David Holmes-2
In reply to this post by Gerard Ziemski-2
On Fri, 19 Feb 2021 17:54:13 GMT, Gerard Ziemski <[hidden email]> wrote:

>> On Mac ARM hardware running x86 JDK under Rosetta emulation, a div by 0 instruction causes the VM to crash.
>>
>> The proposed fix (a workaround) for hotspot is to add **FPE_FLTINV** to the signal handler.
>>
>> The actual fix needs to be done in macOS by Apple as the expected signal type here is **FPE_FLTDIV**
>> This issue has been filed with Apple and they are tracking it.
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
>
>   check whether the process is translated

Hi Gerard,

The new VM_Version check should be in vm_version_bsd_x86.cpp so that we don't need to ifdef the code in the generic x86 file.

I don't think we need make is_cpu_emulated available on all platforms, jusyt bsd-x86.

Thanks,
David

-------------

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2615
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 [v4]

Gerard Ziemski-2
On Mon, 22 Feb 2021 04:15:45 GMT, David Holmes <[hidden email]> wrote:

> Hi Gerard,
>
> The new VM_Version check should be in vm_version_bsd_x86.cpp so that we don't need to ifdef the code in the generic x86 file.
>
> I don't think we need make is_cpu_emulated available on all platforms, jusyt bsd-x86.
>
> Thanks,
> David

I figured we would need eventually something similar for other OS (any x86_64 based OS being ported to aarch64), so I put the API into `vm_version_x86`.

`os_bsd_x86.hpp/.cpp` still needs the `#if __APPLE__`, but I did remove the API from ` vm_version_x86`

-------------

PR: https://git.openjdk.java.net/jdk/pull/2615
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8261397: Try Catch Method Failing to Work When Dividing An Integer By 0 [v5]

Gerard Ziemski-2
In reply to this post by Gerard Ziemski-2
> On Mac ARM hardware running x86 JDK under Rosetta emulation, a div by 0 instruction causes the VM to crash.
>
> The proposed fix (a workaround) for hotspot is to add **FPE_FLTINV** to the signal handler.
>
> The actual fix needs to be done in macOS by Apple as the expected signal type here is **FPE_FLTDIV**
> This issue has been filed with Apple and they are tracking it.

Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:

  only add is_cpu_emulated() to bsd platform, where currently needed

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2615/files
  - new: https://git.openjdk.java.net/jdk/pull/2615/files/65dd76da..3bfe8ebd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2615&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2615&range=03-04

  Stats: 4 lines in 2 files changed: 1 ins; 3 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2615.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2615/head:pull/2615

PR: https://git.openjdk.java.net/jdk/pull/2615
12