We Keep Coding

Why do I keep getting this SIGBUS error code on my MacOS when trying to run a JavaFx Project on Netbeans?

Whenever I try to run my JavaFX problem I encounter a MacOS error, My code runs fine on other devices so I am not sure what is wrong.
Im using an M1 mac, with Java 17 and JavaFX up to the latest version. When running the JavaFX App, it opens up the gui for either 1 second or 30 seconds before crashing and spitting out the error provided. Any help would be greatly appreciated, and if you have other questions or need more info lmk.
I believe it's a problem with a /private/TMP folder or something with what I've seen online, but I can be completely wrong since that folder is basically empty right now so I don't see it being full or whatever.
If anyone can help or has any idea, I would really appreciate some feedback.
A fatal error has been detected by the Java Runtime Environment:
SIGBUS (0xa) at pc=0x000000010c0314f0, pid=1056, tid=28943
JRE version: Java(TM) SE Runtime Environment (17.0.1+12) (build 17.0.1+12-LTS-39)
Java VM: Java HotSpot(TM) 64-Bit Server VM (17.0.1+12-LTS-39, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)
Problematic frame:
v ~StubRoutines::SafeFetchN
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/peter/Desktop/BookStore/hs_err_pid1056.log
If you would like to submit a bug report, please visit:
https://bugreport.java.com/bugreport/crash.jsp
The crash happened outside the Java Virtual Machine in native code.
See problematic frame for where to report the bug

Update your JavaFX version to the most recent available.
JavaFX bug reports mentioning:
stubroutines::SafeFetchN
are closed as duplicates of JDK-8275723, even though the crash error message there is slightly different.
Bug reports related to this are logged when trying to run early versions (less than 17.0.2) of JavaFX 17 on some M1 macs using the Monterey OS.
The linked case report recommends using JavaFX version 17.0.2 when it is released and notes a fix is also in the most recent JavaFX 18 early access releases, which are available for download.
Asker notes in comments:
I updated the JavaFx to 18 and it's all good
Another asker noted in comments on a duplicate:
I just tried to run the project with a JDK version 17.0.2 and it seems to work perfectly fine
I have a 17.0.2 one (newest version from Bellsoft Liberica).

Yes the issue is with JDK 17 Oracle. I have tried Azul Zulu JDK 17.34.19 and its working great! I am linking it below
Azul Zulu JDK 17 Download Page

Ubuntu A fatal error has been detected by the JRE

I have written a java program that plays videos using vlcj on a frame. I use NativeDiscovery().discover() to get the libvlc libraries, the program works on windows but on ubuntu NativeDiscovery().doscover() returns false and I get a fatal error with the log file: This is just the beginning of the log file
A fatal error has been detected by the Java Runtime Environment:
SIGSEGV (0xb) at pc=0xb7674f98, pid=21800, tid=2195979072
JRE version: 7.0_25-b30
Java VM: OpenJDK Server VM (23.7-b01 mixed mode linux-x86 )
Problematic frame:
C [libc.so.6+0x12ef98] _IO_file_underflow+0x68
Filed to write core dump. Core dumps have been disabled. To enable core dumping, try ulimit -c unlimited" before starting Java again
If you would like to submit a bug report, please include
instructions on how to reproduce the bug and visit:
https://bugs.launchpad.net/ubuntu/+source/openjdk-7/
Thanks guys for your help.

I had to face a bunch of similar errors as i worked with VLCJ last year. I dont know, if you have exactly the same error, as i had, but i can give you some hints:
in my case i had to use oracles java 7, not the openJDK
i had to set some symbolic links ("ln -s ...") to the vlc-executables, because the versionnumber was not the one, vlcj
expected.
I dont know, if this is useful to you, but as i was in your situation, i was grateful for every hint.

The reason could be the usage of the OpenJDK.
Try the OracleJDK.

This is almost certainly the same issue as https://github.com/caprica/vlcj/issues/62.
There is a long history of investigations into that issue which you can see in the comments at that github issue page.
The short version is that for some currently unknown reason:
a combination of 32-bit Java7 JVM and 32-bit Ubuntu triggers this fatal error;
the error pertains to the parsing of LUA scripts when VLC plays media;
deleting VLC's LUA scripts will resolve the problem - BUT things like YouTube will stop working (since VLC's YouTube support requires LUA);
It will work with Java6 on 32-bit Ubuntu;
It will work with Java7 on 64-bit Ubuntu;
If you write the equivalent "C" program, it will work - so something in the JVM is triggering the problem.
Unfortunately, I do not know if the bug is in Ubuntu's LUA build or the Oracle/OpenJDK build of the Java7 JVM.
Switching from OpenJDK to Oracle's JDK or vice versa will likely make no difference.

I encountered a similar problem. I solved it by removing openjdk and reinstalling it :)

In my case, installing Oracle JDK and setting up as default jdk has solved the problem.

"Execution Protection Violation" when running Jar in Windows 7

I'm trying to export a game written in LibGDX, Java and Flixel-Android. The game was developed on a Mac, and runs on other Mac systems in Jar form. When running it on a Windows 7 machine it quits before completely starting up, and I get this dump:
A fatal error has been detected by the Java Runtime Environment:
EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x04a2b400, pid=5824,
tid=5912
JRE version: 7.0_09-b05 Java VM: Java HotSpot(TM) Client VM
(23.5-b02 mixed mode, sharing windows-x86 ) Problematic frame: C
0x04a2b400
Failed to write core dump. Minidumps are not enabled by default on
client versions of Windows
If you would like to submit a bug report, please visit:
http://bugreport.sun.com/bugreport/crash.jsp The crash happened
outside the Java Virtual Machine in native code. See problematic
frame for where to report the bug.
The console window also prints "Execution protection violation" shortly before showing this, and then dumps the above into a text file as well. The text file includes a far, far longer dump that I won't post here unless people think necessary.
I have no idea what might be causing this, and I don't have much time to work it out! Anyone have any leads?
EDIT - I've narrowed it down to a section of code that loads a file from LibGDX's store. Is this a native library issue?
EDIT - It's somehow related to changing the size of a piece of text in Flixel-Android.

I would assume that the native library doesn't work properly on windows and/or with Java 7 (I know, this is quite obvious).
Bear in mind that Android's java is is java 1.5 compliant, so I could see that library breaking on java 7. I would verify which java versions are supported on the website of the library.
edit
It looks like java 7 is the culprit: http://code.google.com/p/libgdx/issues/detail?id=824 .
I think I'm an expert google user...

Java VM: reproducible SIGSEGV on both 1.6.0_17 and 1.6.0_18, how to report?

EDIT: This reproducible SIGSEGV happens on a Linux machine with more than one proc and more than 2GB of mem, so Java is defaulting to the -server mode. Interestingly enough if I force "-client" there's no crash anymore... (I'm still not too sure what to do with my reproducible SIGSEGV but it's interesting nonetheless).
First note that this is a bit related but not identical to the following because in our case it's only a SIGSEGV that happens, and we can reliably trigger it:
JVM OutOfMemory error "death spiral" (not memory leak)
It's related because it happens when we feed our app with a "deluge of data": data are coming from text files and then number-crunched (yes, financial number crunching in Java).
I can reliably trigger a JVM to SIGSEGV using only valid Java code.
NOTE: I can invariably crash both JVM 1.6.0_17 adn JVM 1.6.0_18 and this question is not about how to workaround this issue (for example playing with VM parameters may fix the issue but I'm not after that, I want to know what to do with this always-reproducable SIGSEGV).
I've got a workaround which simply consists in using Java 1.5 when launching our app (while still using Java 1.6 to run IntelliJ IDEA, etc. on the same machine, simultaneously), but my question is if this should be reported or not and, if it should, how to report it knowing that the log itself contains proprietary information (the full hs_err_..._log).
Hardware error can be ruled out for:
this is happening on a workstation that regularly reaches months of uptime (I only reboot it when critical security patches affecting my trimmed down and hardened Debian Linux are issued, which really doesn't happen often) and on which applications never crash (making it very unlikely that it's an hardware issue on that machine [more below])
same application works perfectly on that same machine under a JVM 1.5 under the same load (this is how I'm testing the app: I simply launch it under a 1.5 VM)
same application works perfectly fine on more than one hundreds clients machine under the same (gigantic) load (never crashed once on Windows + JVM 1.5 or 1.6 and never crashed once on OS X + JVM 1.5 or 1.6 [a crash would mean an instant phone call from the client])
other application on that same machine and same 1.6.0_17 or 1.6.0_18 JVM never crash (for example I've got two instances of IntelliJ IDEA running as two different users on that same machine and they don't crash)
machine is tested with memtest "regularly" (before installing a new OS, which last happened when I installed Debian Lenny, not that long ago)
Here's the reproducible-on-demand SIGSEGV:
... $uname -a
Linux saturn 2.6.26-2-686 #1 SMP Wed Nov 4 20:45:37 UTC 2009 i686 GNU/Linux
... $ export /home/wizard/jdk1.6.0_17/bin:$PATH
... $ java -version
java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)
Launch the app, feed it a "deluge of data", wait a few seconds...
Then, invariably, for 1.6.0_17:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xb76d0080, pid=30793, tid=2514328464
#
# JRE version: 6.0_17-b04
# Java VM: Java HotSpot(TM) Server VM (14.3-b01 mixed mode linux-x86 )
# Problematic frame:
# V [libjvm.so+0x4bc080]
#
# An error report file with more information is saved as:
# /home/wizard/hs_err_pid30793.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
(note that the line '[libjvm.so+0x4bc080]' is consistent for 1.6.0_17 at every SIGSEGV)
or for 1.6.0_18:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xb77468f0, pid=722, tid=2514516880
#
# JRE version: 6.0_18-b07
# Java VM: Java HotSpot(TM) Server VM (16.0-b13 mixed mode linux-x86 )
# Problematic frame:
# V [libjvm.so+0x4d88f0]
#
# An error report file with more information is saved as:
# /home/wizard/hs_err_pid722.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
Aborted
(note that the line "[libjvm.so+0x4d88f0]" is consistent for 1.6.0_18 at every SIGSEGV)
The problem is that the log file contains proprietary information
that cannot be shared.
Reproducing a "tiny test case" that reproduce the issue ain't realistic either: it's similar to the issue linked above, this only happens when a "deluge of data" is feeded to the app.
Note that the exact same application, on exactly the same hardware, with exactly the same JVM but another version of Linux (I had Debian Etch previously) did NOT trigger that SIGSEGV once.
But this doesn't mean the JVM isn't at fault: it could still be a JVM issue.
Should I report this and how? (keeping in mind that writing a "reproducible tiny test case" is delusional and that the log contains proprietary information that shouldn't be leaked). Should I just edit the log and send it?
What's the procedure to report such reproducible SIGSEGV when your log contains proprietary information and when a test case reproducing the issue ain't realistically doable?
Did any of you have success opening such a bug and then see it solved in a subsequent Java release?
Do you think it's good "for the Java community" to report such an issue or I just shouldn't bother because it's not important?

I got similar problem upgrading to JDK 1.6_18 and it seems solved using the following options:
-server
-Xms256m
-Xmx748m
-XX:MaxPermSize=128m
-verbose:gc
-XX:+PrintGCTimeStamps
-Xloggc:/tmp/gc.log
-XX:+PrintHeapAtGC
-XX:+PrintGCDetails
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath="/tmp"
-XX:+UseParallelGC
-XX:-UseGCOverheadLimit
# Following options just to remote monitoring with jconsole, useful to see JVM behaviour at runtime
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=12345
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Djava.rmi.server.hostname=MyHost
I still didn't double check (it is a production environment), but I think the error was due to two reasons:
1) Wrong setting about heap and/or Permanent space (I think JDK 1.6 needs more space in heap and permanent than previous JVM versions) caused an OutOfMemoryError, but
2) in the wrong original setting somebody wrote
-XX:+HeapDumpOnOutOfMemoryError="/tmp"
and not
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath="/tmp"
so probably JVM was not able to write the heapdump and we got SIGSEGV only (previous versions wrote heap dump in the working directory).
Check -server -XX:+UseParallelGC -XX:-UseGCOverheadLimit options too. I think playing with VM parameters is not a workaround, but the right approach also because garbage collector (and not only) changed between 1.5 and 1.6.

The problem is that the log file
contains proprietary information that
cannot be shared. Reproducing a "tiny
test case" that reproduce the issue
ain't realistic either
If you can't provide Sun with a reproducible test case, they won't even look at it. Chance are good that they will ignore it even if you do provide a usable test case. The bug submission process at Sun leaves a lot to be desired.
Should I report this and how?
If you can't come up with a reproducible test case, don't bother. If they can't reproduce the issue, what do you expect them to do?
Note that the exact same application,
on exactly the same hardware, with
exactly the same JVM but another
version of Linux (I had Debian Etch
previously) did NOT trigger that
SIGSEGV once.
Does it work on a different box with the same hardware and same version of Linux?

If it helps, the bug submission link in your crash report has this disclaimer:
In addition, Sun Microsystems respects your desire for privacy. Personal data collected from this program will not be sold, given or shared with organizations external to Sun. We will use this data for communications with you to clarify issues regarding the report you submitted and/or status of that report. The issues that you report may be made available to other JDC Members or Sun customers, however your personal data will be kept confidential. If you are not comfortable with the above conditions, please do not press the Submit button. If you have any questions, please refer to our Privacy Policy.
Personally, I would report it if it was feasible to hand over the code segment in question with logs, if the data is not too sensitive (perhaps data can be masked or obfuscated in logs?).
It's impossible for you to really judge if the bug is "important" or not for others unless you can know what actually causes it. Reporting it might be the first step in Sun's engineers finding out the cause of something serious.

The very first question you should ask yourself is:
Am I using an officially supported Linux distribution?
If not, switch to one that is.
If you are, then report it to Sun!

GWT 1.6.4 on FreeBSD?

Anyone have GWT 1.6.4 running on FreeBSD? Our build server is a FreeBSD box, and dies with the following when we try to compile:
# An unexpected error has been detected by Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x0000000800d0c724, pid=4749[thread 34370233088 also had an error], tid=0xa02d80
#
# Java VM: Diablo Java HotSpot(TM) 64-Bit Server VM (10.0-b23 mixed mode bsd-amd64)
# Problematic frame:
# V [libjvm.so+0x20c724]
#
# An error report file with more information is saved as:
# /usr/home/username/reporting/hs_err_pid4749.log
#
# Please submit bug reports to freebsd-java#FreeBSD.org
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
Interestingly, Maven seems to include gwt-dev-1.6.4-linux.jar in the classpath, presumably because there is no version for FreeBSD; I don't know if this is related or not. We are just trying to compile, not use hosted mode, so I don't believe any native libraries are actually required. This used to work fine for us with GWT 1.5.

If you search Google for that frame (libjvm.so+0x20c724) you find some relevant recent threads on the freebsd-java list.
Looks like the problem might be related to IPv6? The solution proposed there was to add
-Djava.net.preferIPv6Addresses=false
-Djava.net.preferIPv4Stack=true
to the configuration.
It's unusual to see a FreeBSD build system for java; there isn't a lot of flexibility or support for Java on that platform. Is your product deployed on FreeBSD as well? If the solution above doesn't work, you may have to get more closely engaged with the freebsd-java community or else consider trying another platform for the build.

We seem to have dodged this by using JDK5 to compile our GWT-based code. Not a perfect solution, but a work-around.