Bazel installer crashes on macOS Monterey

dannote commented 3 years ago

Description of the problem / feature request:

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

curl -fLO https://github.com/bazelbuild/bazel/releases/download/4.2.1/bazel-4.2.1-installer-darwin-arm64.sh
chmod +x bazel-4.2.1-installer-darwin-arm64.sh
./bazel-4.2.1-installer-darwin-arm64.sh

What operating system are you running Bazel on?

macOS 12.0 Beta (21A5506j)

Have you found anything relevant by searching the web?

Unfortunately no

Any other information, logs, or outputs that you want to share?

# Binary package at HEAD (@02ad3e3bc6970)
   - [Commit](https://github.com/bazelbuild/bazel/commit/02ad3e3bc6970)
Uncompressing......Starting local Bazel server and connecting to it...
Server crashed during startup. Now printing /private/var/tmp/_bazel_dannote/e98556b45cb4c4c447efab3c031e2cde/server/jvm.out
Exception in thread "main" java.lang.BootstrapMethodError: bootstrap method initialization exception
    at java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(Unknown Source)
    at java.base/java.lang.invoke.CallSite.makeSite(Unknown Source)
    at java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(Unknown Source)
    at java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(Unknown Source)
    at java.management/sun.management.VMManagementImpl.getVmId(Unknown Source)
    at java.management/sun.management.RuntimeImpl.getName(Unknown Source)
    at com.google.devtools.build.lib.util.SimpleLogHandler.getPidString(SimpleLogHandler.java:629)
    at com.google.devtools.build.lib.util.SimpleLogHandler.<init>(SimpleLogHandler.java:370)
    at com.google.devtools.build.lib.util.SimpleLogHandler.<init>(SimpleLogHandler.java:330)
    at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
    at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
    at java.base/java.lang.reflect.Constructor.newInstance(Unknown Source)
    at java.base/java.lang.Class.newInstance(Unknown Source)
    at java.logging/java.util.logging.LogManager.createLoggerHandlers(Unknown Source)
    at java.logging/java.util.logging.LogManager$4.run(Unknown Source)
    at java.logging/java.util.logging.LogManager$4.run(Unknown Source)
    at java.base/java.security.AccessController.doPrivileged(Native Method)
    at java.logging/java.util.logging.LogManager.loadLoggerHandlers(Unknown Source)
    at java.logging/java.util.logging.LogManager.initializeGlobalHandlers(Unknown Source)
    at java.logging/java.util.logging.LogManager$RootLogger.accessCheckedHandlers(Unknown Source)
    at java.logging/java.util.logging.Logger.getHandlers(Unknown Source)
    at java.logging/java.util.logging.Logger.log(Unknown Source)
    at com.google.common.flogger.backend.system.AbstractBackend.log(AbstractBackend.java:76)
    at com.google.common.flogger.backend.system.SimpleLoggerBackend.log(SimpleLoggerBackend.java:31)
    at com.google.common.flogger.AbstractLogger.write(AbstractLogger.java:137)
    at com.google.common.flogger.LogContext.logImpl(LogContext.java:566)
    at com.google.common.flogger.LogContext.log(LogContext.java:686)
    at com.google.devtools.build.lib.analysis.BlazeVersionInfo.logVersionInfo(BlazeVersionInfo.java:64)
    at com.google.devtools.build.lib.analysis.BlazeVersionInfo.setBuildInfo(BlazeVersionInfo.java:79)
    at com.google.devtools.build.lib.bazel.Bazel.main(Bazel.java:84)
Caused by: java.lang.invoke.StringConcatException: Generator failed
    at java.base/java.lang.invoke.StringConcatFactory.generate(Unknown Source)
    at java.base/java.lang.invoke.StringConcatFactory.doStringConcat(Unknown Source)
    at java.base/java.lang.invoke.StringConcatFactory.makeConcatWithConstants(Unknown Source)
    ... 31 more
Caused by: java.lang.NullPointerException
    at java.base/java.lang.String.length(Unknown Source)
    at java.base/java.lang.AbstractStringBuilder.append(Unknown Source)
    at java.base/java.lang.StringBuilder.append(Unknown Source)
    at java.base/java.lang.invoke.ClassSpecializer.classSig(Unknown Source)
    at java.base/java.lang.invoke.ClassSpecializer.classSig(Unknown Source)
    at java.base/java.lang.invoke.ClassSpecializer$Factory$1Var.<init>(Unknown Source)
    at java.base/java.lang.invoke.ClassSpecializer$Factory.generateConcreteSpeciesCodeFile(Unknown Source)
    at java.base/java.lang.invoke.ClassSpecializer$Factory.generateConcreteSpeciesCode(Unknown Source)
    at java.base/java.lang.invoke.ClassSpecializer$Factory.loadSpecies(Unknown Source)
    at java.base/java.lang.invoke.ClassSpecializer.findSpecies(Unknown Source)
    at java.base/java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(Unknown Source)
    at java.base/java.lang.invoke.LambdaFormEditor.newSpeciesData(Unknown Source)
    at java.base/java.lang.invoke.LambdaFormEditor.bindArgumentForm(Unknown Source)
    at java.base/java.lang.invoke.LambdaFormEditor.bindArgumentI(Unknown Source)
    at java.base/java.lang.invoke.BoundMethodHandle.bindArgumentI(Unknown Source)
    at java.base/java.lang.invoke.MethodHandles.insertArgumentPrimitive(Unknown Source)
    at java.base/java.lang.invoke.MethodHandles.insertArguments(Unknown Source)
    at java.base/java.lang.invoke.StringConcatFactory$MethodHandleInlineCopyStrategy.generate(Unknown Source)
    ... 34 more

philwo commented 3 years ago

Thanks for the report! I'll upgrade one of my machines to Monterey and will try to reproduce.

philwo commented 3 years ago

@meteorcloudy FYI

keith commented 3 years ago

I filed an issue with Azul about this, it's a known issue:

I understand that Zulu11 is crashing immediately upon start on your M1 Mac running on Monterey.

I suspect that you have the latest developer build (eg. Beta-6) and if so, this is a known issue that should be remedied shortly.

...

2.)  If so, there are a number of temporary work-arounds available until we release a fix.
  (a)  One option is to avoid this issue (with C2 compiler) by adding the following JVM parameters:  -XX:+TieredCompilation -XX:TieredStopAtLevel=1
This can be accomplished by modifying your JVM startup parameters, or defining the environment variable _JAVA_OPTIONS="-XX:+TieredCompilation -XX:TieredStopAtLevel=1"
If that doesn't work, then try using "JAVA_OPTS" instead.  Please let me know if this (temporarily) resolves your issue satisfactorily or if you need further help with the solution.

  (b) Since this issue began with a change made by Apple in the Beta-6 version of Monterey, another option is to use an earlier beta version of Monterey or stick to a commercially available build.  Please let me know if this is an option for you.

  (c) This issue affects Zulu11, Zulu13 and Zulu15.  So another option is to download Zulu16, Zulu17 or Zulu18.  Please let me know if that is an option for you.

  (d) Finally, we have a solution in testing right now and it should be released imminently.  You could wait until a fix is released (with a version greater than 11.50.19).

philwo commented 3 years ago

Excellent! Then we can just bump our embedded JDK to the latest version once the fix is out - and maybe we have to release a patch release for 4.2.1 if Apple doesn't want to fix it on their side and restore compatibility with the older OpenJDK. 😅

FYI @katre

keith commented 3 years ago

So another option is to download Zulu16, Zulu17 or Zulu18

It sounds like if we were on one of these versions it would already be fixed? Is updating to one of those feasible?

philwo commented 3 years ago

FYI @meisterT, our JDK expert.

Updating the embedded JDK to OpenJDK 17 LTS shouldn’t be too hard, but we’d need to run performance regression tests first. I also wouldn’t feel so comfortable bumping the embedded JDK from 11 to 17 in a patch release of our Bazel LTS version 😅

meisterT commented 3 years ago

I would be hesitant as well to bump the JDK in a patch release. But we should aim to do it before Bazel 5.0 is cut.

meteorcloudy commented 3 years ago

@dannote As a workaround for now, maybe you can install a compatible JDK version with Monterey and try with the Bazel binary without the embedded JDK? https://github.com/bazelbuild/bazel/releases/download/4.2.1/bazel_nojdk-4.2.1-darwin-arm64

dannote commented 3 years ago

@meteorcloudy I'll try, thank you

keith commented 3 years ago

This appears to be fixed in monterey beta 7, I can no longer repro this crash 🎉

dannote commented 3 years ago

It looks like bazel_nojdk-4.2.1-darwin-arm64 works fine with OpenJDK 17

dannote commented 3 years ago

It seems that it's a bit too early to bump to OpenJDK 17. I ran into issues related to JSR 376:

Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make java.lang.String(byte[],byte) accessible: module java.base does not "opens java.lang" to unnamed module @22272bbe
    at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
    at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
    at java.base/java.lang.reflect.Constructor.checkCanSetAccessible(Constructor.java:188)
    at java.base/java.lang.reflect.Constructor.setAccessible(Constructor.java:181)
    at com.google.devtools.build.lib.unsafe.StringUnsafe.<init>(StringUnsafe.java:75)
    at com.google.devtools.build.lib.unsafe.StringUnsafe.initInstance(StringUnsafe.java:56)
    at com.google.devtools.build.lib.unsafe.StringUnsafe.<clinit>(StringUnsafe.java:37)
    ... 19 more

keith commented 3 years ago

Given the fix in beta 7, unless folks can reproduce with that newer version, we can probably close this.

bazelbuild / bazel