bazel: Bugfix, Update to version 6.1.2; PG bazel #16149
Conversation
|
Notifying maintainers: |
|
CI error: I do not observe this with a trace build. I recommend that a reviewer confirm this and merge whether or not the CI completed.
|
I'll add this to my to-do list, unless @reneeotten or someone else wants to take a look. ;-) |
|
I confirm that this latest version builds locally on: |
essandess
changed the title
essandess
changed the title
There was a problem hiding this comment.
CI failed:
FATAL: bazel crashed due to an internal error. Printing stack trace:
java.lang.ExceptionInInitializerError
at com.google.devtools.build.lib.actions.ParameterFile.writeContentLatin1(ParameterFile.java:141)
at com.google.devtools.build.lib.actions.ParameterFile.writeContent(ParameterFile.java:120)
at com.google.devtools.build.lib.actions.ParameterFile.writeParameterFile(ParameterFile.java:112)
at com.google.devtools.build.lib.analysis.actions.ParameterFileWriteAction$ParamFileWriter.writeOutputFile(ParameterFileWriteAction.java:172)
at com.google.devtools.build.lib.exec.FileWriteStrategy.beginWriteOutputToFile(FileWriteStrategy.java:58)
at com.google.devtools.build.lib.analysis.actions.FileWriteActionContext.beginWriteOutputToFile(FileWriteActionContext.java:49)
at com.google.devtools.build.lib.analysis.actions.AbstractFileWriteAction.beginExecution(AbstractFileWriteAction.java:66)
at com.google.devtools.build.lib.actions.Action.execute(Action.java:133)
at com.google.devtools.build.lib.skyframe.SkyframeActionExecutor$5.execute(SkyframeActionExecutor.java:957)
at com.google.devtools.build.lib.skyframe.SkyframeActionExecutor$ActionRunner.continueAction(SkyframeActionExecutor.java:1124)
at com.google.devtools.build.lib.skyframe.SkyframeActionExecutor$ActionRunner.run(SkyframeActionExecutor.java:1082)
at com.google.devtools.build.lib.skyframe.ActionExecutionState.runStateMachine(ActionExecutionState.java:160)
at com.google.devtools.build.lib.skyframe.ActionExecutionState.getResultOrDependOnFuture(ActionExecutionState.java:93)
at com.google.devtools.build.lib.skyframe.SkyframeActionExecutor.executeAction(SkyframeActionExecutor.java:516)
at com.google.devtools.build.lib.skyframe.ActionExecutionFunction.checkCacheAndExecuteIfNeeded(ActionExecutionFunction.java:827)
at com.google.devtools.build.lib.skyframe.ActionExecutionFunction.computeInternal(ActionExecutionFunction.java:323)
at com.google.devtools.build.lib.skyframe.ActionExecutionFunction.compute(ActionExecutionFunction.java:161)
at com.google.devtools.build.skyframe.AbstractParallelEvaluator$Evaluate.run(AbstractParallelEvaluator.java:571)
at com.google.devtools.build.lib.concurrent.AbstractQueueVisitor$WrappedRunnable.run(AbstractQueueVisitor.java:382)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
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 @297e2f87
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:61)
at com.google.devtools.build.lib.unsafe.StringUnsafe.<clinit>(StringUnsafe.java:36)
... 22 more
ERROR: Could not build Bazel
I confirm that this builds and runs on: macOS 13.3.1 22E261 x86_64 Good luck tracking down whatever java thing breaks on the CI 🙃 |
essandess
changed the title
|
@essandess which java version have you use? |
|
@essandess the root cause of issue: |
|
@essandess I've opened a PR into your branch which fixes CI: essandess#2 The run: https://github.com/catap/macports-ports/actions/runs/4860773891 Let unblock it! |
No, The java PG does its best to satisfy whatever requirements it is asked to. In this case there is I think something fishy in the environment on the CI machine causing issues. The message Comes from https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/java-1.0.tcl#L90 and shows that an attempt to run However.... That path then appears to fail a test to confirm its a valid directory, at https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/java-1.0.tcl#L105 as that is the only way the message can appear, and at this point the java PG gives up trying to satisfy the requirements, as its run out of options to do so, and just uses the default, which in this case appears to be for version 17. So the primary question is why does the path get listed as a valid JM alternative, but then fail the I don't think there is anything wrong with the java PG here, it is just doing its best to work with the environment it is presented with. |
|
@cjones051073 yes, the issue that Github runners has 3rd party JDK. As soon as I've removed it, the CI had passed. I think that ignoring 3rd party JDKs isn't the right move. Cleaner to remove it from Github runners. |
A priori there is nothing wrong with third party JDKs, assuming they function correctly... So for me the question I ask above is still relevant, why is the JDK that is made available failing the |
Because it isn't a directory :) More of that this path doesn't exists. See, it returns a path: and here => seems something is quite wrong with this JDK and and easy way is remove it, and use MacPorts JDK. |
I do not agree with the changes you make in essandess#2 . |
So I guess my question now is who should the above buggy path be reported to ? |
|
@cjones051073 that's wired. The diff below fixes an issue, see: https://github.com/catap/macports-ports/actions/runs/4861461977 --- a/_resources/port1.0/group/java-1.0.tcl
+++ b/_resources/port1.0/group/java-1.0.tcl
@@ -165,7 +165,9 @@ namespace eval java {
ui_debug "java-portgroup: Detected JVMs: $versions_found"
# Match the systems JVMs with the one requested by MacPorts
# Higher JVM Versions win
- return [match_jvm_version $version_requested $versions_found]
+ set filtered [match_jvm_version $version_requested $versions_found]
+ ui_debug "java-portgroup: filtered JVM: $filtered"
+ return $filtered
} |
... or... its possible what is being returned is being incorrectly munged by the proc in the java PG https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/java-1.0.tcl#L171 However to judge if thats the case or not we need to see the raw output from when run on the CI machine. |
You're reading my mind and I'm running it right now. So, here the output: => environment is innocent and issue from java PG, or at least seems so. |
Yeah, it looks like the logic falls over when there are mulitple paths for exactly the same version. I guess this was a scenario never expected.... So the correct fix here is to attempt to deal with this in some way... |
The core issue here is the use of https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/java-1.0.tcl#L189 If you call that twice for exactly the same key (`$vers) then you get what we seem, the path string for that version is all paths munged together. A simple fix is to use |
|
@cjones051073 thanks, you was faster than me :) It is testing right now here: https://github.com/catap/macports-ports/actions/runs/4862643389 I really think that we had found the cause and it I feel that I've encountered it once but never had motivated enough to dig. |
@catap Those builds above are still using essandess#2 as I see in the macOS13 logs messages you added there Please cancel these and start them again without this MR... ... and of course instead with #18496 |
|
Sorry, tooo many branches! The right one: https://github.com/catap/macports-ports/actions/runs/4862901100 |
OK, those seem to have worked. I see the warnings I would expect and a valid JVM path is now picked. I am reasonably happy #18496 is an improvement over what is currently there, so I think I will merge it. One thing I do not do, as I wouldn't really know how, is make any decision on which path to use when there are multiple for the same (major) version. Currently its just whichever is the last listed by |
|
@cjones051073 seems that your PR works as expected |
yup. I've merged the Java PG fix and restarted the tests here. |
|
@cjones051073 I've supprised that it doesn't require to be rebased |
|
Ah, i assumed the tests would do that themselves... |
|
@essandess Please rebase your branch here so we can retest. |
|
Yahoo! |
|
So are we ready to merge this then...? |
|
Just tested on 10.15/Xcode 12, and I did encounter two issues:
With those two changes in play, though, |
|
Thanks everyone for getting this working! |
|
Quick update: I'm now able to build Bazel for 10.14, by relaxing the Xcode/Clang minimum: Xcode 10.3/Clang 10 are sufficient, and the build looks good. That change was included in Herby's update to Bazel 6.2, via PR: #18601 As for |
Description
Cherry picked from #15397.
Type(s)
Tested on
macOS 12.6 21G115 x86_64
Xcode 14.0 14A309
Verification
Have you
port lint --nitpick?sudo port test?sudo port -vst install?