I have a question. We are trying to set up command...
# box-products
b
I have a question. We are trying to set up command box on a new MacBook. (with the M1 processor) We didn't install java globally but we downloaded Mac 64-bit JRE from the commandbox website. When we try to start our server the startup process does not complete but it ends with this error: Any idea's what could be causing this?
Copy code
[DEBUG] Runwar: StopMonitor listening for password
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00000001307a5cbc, pid=4465, tid=7171
#
# JRE version: OpenJDK Runtime Environment Temurin-11.0.14.1+1 (11.0.14.1+1) (build 11.0.14.1+1)
# Java VM: OpenJDK 64-Bit Server VM Temurin-11.0.14.1+1 (11.0.14.1+1, mixed mode, tiered, compressed oops, g1 gc, bsd-amd64)
# Problematic frame:
# C  [libawt_lwawt.dylib+0x3acbc]  Java_sun_lwawt_macosx_CRobot_mouseEvent+0x34b
#
# 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/***/Dev/legacy-api/hs_err_pid4465.log
#
# If you would like to submit a bug report, please visit:
#   <https://github.com/adoptium/adoptium-support/issues>
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
[DEBUG] Runwar: #
[ERROR] #
[DEBUG] Runwar: Server exit code is: 134
ERROR (5.4.2+00453)
Server process returned failing exit code [1]
The problem has been found. In the server.conf we set a custom tray icon. We discovered that if you disable the tray icon there is no problem and the server starts as normal.
z
lucee 5.3.9-RC now supports mac m1 jdks
b
@birdy1980 Sadly, the library we use for the tray icons has fallen far behind and still doesn't support java 9+ very well https://github.com/dorkbox/SystemTray/issues/119
👍🏻 1
I logged that bug 2 years ago. The developer, who only seems to work on the project in his spare time, allegedly fixed the issue a year ago, but still hasn't released a new version of the library.
It still works ok on Windows, but Mac support is very spotty
And for whatever reason, since it's loading native libraries, when it fails, it tends to take down the entire JVM in a manner that I can't just try/catch 😕
Please chime in on that ticket and maybe the developer will release his fix for us fingers crossed
👍🏻 1
What I'm considering doing is disabling the tray icons for Mac in the next version of CommandBox until this is fixed.
p
If it was a choice between having a stable native version running on M1 Macs and the tray icon, I vote for stability.
b
@Peter Amiri I put in this ticket, and already committed the change https://ortussolutions.atlassian.net/browse/COMMANDBOX-1444 but not everyone at Ortus is a fan of it. One of the biggest tricks is I'm not sure I can always correctly guess in the code ahead of time whether the tray icon is going to work
The commit I added just disables it always on Mac and Linux, but I know there are some people that it works for depending on their setup
p
@bdw429s Could it be available for someone to launch if they wanted it. So it was off by default, but you could launch it if you wanted it and if it works for you then great but if it doesn't, then we'll we warned you.
b
Yes, of course. That's what I did in the ticket. Off by default, but you can turn it back on with
Copy code
server set trayEnable=true
👍🏻 1
But to be clear, that's specifically what I got some pushback on from the Ortus team who thought turning it off for all Mac/LInux users by default was too heavy handed 😉
b
Thanks for the input and the quickfix 🙂