Problem in enabling core dumps

[shaivmehrotra15]

Question

I am a beginner in coding. When I try to run a code in java which throws any exception , instead of the name of the exception such as ArithmeticException or StringIndexOutOfBounds exception, the IDE shows a long message starting in "A fatal error has been detected by the Java Runtime Environment". It says that the core dumps have been disabled and I am not sure but I think that could be the problem.

I do not know how to fix this as I am only a beginner so any help would be immensely appreciated. Thanks a lot in advance.

Context

For context , this is the entire thing that shows up when an exception occurs:
A fatal error has been detected by the Java Runtime Environment:

SIGFPE (0x8) at pc=0x0000000117134188, pid=1476, tid=7939

JRE version: OpenJDK Runtime Environment AdoptOpenJDK (11.0.9.1+1) (build 11.0.9.1+1)
Java VM: OpenJDK 64-Bit Server VM AdoptOpenJDK (11.0.9.1+1, mixed mode, tiered, compressed oops, g1 gc, bsd-amd64)
Problematic frame:
j ExceptionHandling.MainClass.main([Ljava/lang/String;)V+0 test1

No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again

An error report file with more information is saved as:
/Users/shaivmehrotra/eclipse-workspace/test1/hs_err_pid1476.log
Could not load hsdis-amd64.dylib; library not loadable; PrintAssembly is disabled
Java version:
11.0.11

Your operating system and platform:
macOS Big Sur version 11.2.3 , ARM 64

[tmancill]

Hi @shaivmehrotra15 . I don't think core dumps being disabled is related to this crash.

A few questions and comments:

1. Your sample output references 11.0.9.1+1, but you mention Java version 11.0.11. Does the crash occur when you install and run under 11.0.11?
2. You also refer to ARM 64. Is it correct to assume that that's a typo?
3. What happens when you run your code outside of the IDE? Have you tried running ulimit -c unlimited as suggested in the output to enable core dumps?
4. Can you share your code, or event better, a minimal reproducible test case? I have access to macOS Big Sur and can try to reproduce the behavior, but I think I need more information about your setup and the code to reproduce. What version of Eclipse are you using?

[shaivmehrotra15]

Hi @shaivmehrotra15 . I don't think core dumps being disabled is related to this crash.

A few questions and comments:

1. Your sample output references 11.0.9.1+1, but you mention Java version 11.0.11. Does the crash occur when you install and run under 11.0.11?
2. You also refer to ARM 64. Is it correct to assume that that's a typo?
3. What happens when you run your code outside of the IDE? Have you tried running ulimit -c unlimited as suggested in the output to enable core dumps?
4. Can you share your code, or event better, a minimal reproducible test case? I have access to macOS Big Sur and can try to reproduce the behavior, but I think I need more information about your setup and the code to reproduce. What version of Eclipse are you using?

Hi @tmancill thanks a lot for reaching out to help. I'll try to answer your questions to the best of my knowledge.

1. I mentioned 11.0.11 because when I type javac -version on terminal it shows 11.0.11 . I tried reinstalling JDK 11 but there was no error at the time but when I opened eclipse to run the code again it showed the same error.
2. I use an m1 MacBook Air which has an ARM based chip , that's all I know regarding this thus I wrote ARM 64 as it was mentioned as an example and I assumed that's what that was referring to. My apologies for writing incorrectly as I did not understand what exactly was asked to mention.
3. I tried to run the code on eclipse , VS code and blueJ but each time it shows the exact same result. And yes I did try to enable core dumps. Whenever I type ulimit -c unlimited on terminal nothing really happens so I don't know if it's working or not. I tried to look for other alternatives but could not find any.
4. My code was very simple it was just dividing a number by 0 as I wanted to see what exception it would throw as I was practicing exception handling and try catch block, and weirdly enough , this happens even if I do put the code in the try catch block. The version of eclipse I am using is 2020-12. Please reach out to me regarding any other information that you'd require about my setup and thanks a lot for the help.

[tmancill]

@shaivmehrotra15 Ah, thank you for clearing that up - my mistake for not thinking about the M1-based hardware.

Newer versions of Eclipse bundle the JRE, which is possibly why you're seeing 11.0.11 on the command-line but 11.0.9.1 in your crashes. That is, Eclipse is not using the same JRE/JDK you are installing. Also, it's suspicious that the crash refers to hsdis-amd64.dylib when you are running on an ARM platform.

I'm having a hard time locating the download for Eclipse 2020-12 for Apple Silicon (and I don't have access to that hardware anyway), and I will need to follow-up with instructions on how to enable the ulimit when running under the Eclipse IDE.

In the meantime, you might try installing an updated Eclipse package for your platform to see if the issue still occurs.

[shaivmehrotra15]

@tmancill Okay I will install an updated Eclipse package but as I said the same error comes when I use VS code or BlueJ for that matter as well, which means the error should be independent of the IDE I use I think. But I'll still try reinstalling and get back to you whether I am getting the same error.

I'll wait for your follow-up instructions on the issue.

[shaivmehrotra15]

@tmancill I installed the latest Eclipse package the 2021-03 but it still shows the exact same error.

[tmancill]

@shaivmehrotra15 The problem you are running into with the missing Hotspot disassembler for your OS and architecture appears to be the same issue reported in #211 (comment). There are also some links you might find useful in adoptium/temurin-build#1922. You might try one of the Azul builds and/or watch the progress of adoptium/aqa-tests#2171.

[shaivmehrotra15]

@tmancill I went to #221 which directed me to http://openjdk.java.net/jeps/391, but I do now understand what exactly am I to do on there. Also, I went to https://github.com/microsoft/openjdk-aarch64/releases/tag/16-ea%2B10-macos and downloaded the files and pasted them inside my jdk file( I'm not sure if I had to do that) but nothing happened. I also downloaded Azul's ARM 64 build for JDK-11 inside my JVM file but it did not make any difference either( I'm not sure if I need to do something else after downloading , because I did not) . I also went to #231 who seemed to be getting the exact same problem , which suggested the Azul fix and the https://github.com/microsoft/openjdk-aarch64/releases/tag/16-ea%2B10-macos one so I suppose they should work but they ain't for me so could you please give a small step by step instruction which I could follow as I do not understand what exactly needs to be done.

[tmancill]

Hi @shaivmehrotra15.

After downloading and extracting the new JRE or JDK you will need to configure Eclipse (or VS Code, or whatever IDE you are using) to use it instead of the default, which is often bundled with the IDE. This is done in Eclipse using Window -> Preferences -> Java -> Installed JREs. When you add a new JRE, you will have the option to configure it to be the default for projects.

Within your current project, you may have to change the runtime JRE. You access via Project -> Properties -> Run/Debug Settings -> (select your main class) -> Edit -> JRE [tab] -> Installed JREs and select the desired JRE. When you run your program, you will see the path to the JRE in the top of the Console window. If you're still seeing 11.0.9.1, then the preference hasn't been applied to your project.

In the example below, I've configure Eclipse to use Azul's early access release of JDK 17 for my project; the output on your platform will look different:

I hope this helps. (Because Adoptium doesn't yet support the JVM on this platform and there is already an open issue for that, I feel like we should move any further conversation about configuring the IDE elsewhere.)

[sxa]

Also, it's suspicious that the crash refers to hsdis-amd64.dylib when you are running on an ARM platform.

That is entirely normal and indicates that is running the x86-64 (AMD64) under the Rosetta emulation later instead of running a native ARM64 JVM.

Adopt does have nightly nightly builds for macos/ARM64 being build but they are not yet fully tested or ready to be released.