Mcuxpressoide: JVM terminated. Exit code=1

[scaprile]

I have a Docker container (based on Ubuntu 20.04) with MCUXpressoIDE installed. The IDE works OK. As part of a CI/CD pipeline integration, I'm running mcuxpressoide using its command line for headless builds, in order to test working examples of our product (Cesanta's Mongoose).

Headless builds work, but the process ends with a Java error

cmd line:

/usr/local/mcuxpressoide/ide/mcuxpressoide --launcher.suppressErrors -nosplash -application org.eclipse.cdt.managedbuilder.core.headlessbuild -data workspace -import ../../examples/nxp/rt1060-evk-xpresso-baremetal-builtin -cleanBuild rt1060-evk-xpresso-baremetal-builtin/Debug
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Opening 'rt1060-evk-xpresso-baremetal-builtin'.
16:54:45 **** Clean-only build of configuration Debug for project rt1060-evk-xpresso-baremetal-builtin ****
make -r -j8 clean 
[...]
16:54:45 Build Finished. 0 errors, 0 warnings. (took 434ms)

16:54:56 **** Build of configuration Debug for project rt1060-evk-xpresso-baremetal-builtin ****
make -r -j8 all 
Building file: ../xip/evkbmimxrt1060_flexspi_nor_config.c
Invoking: MCU C Compiler
[...]
Building target: rt1060-evk-xpresso-baremetal-builtin.axf
Invoking: MCU Linker
[...]

Finished building target: rt1060-evk-xpresso-baremetal-builtin.axf

Performing post-build steps
arm-none-eabi-size "rt1060-evk-xpresso-baremetal-builtin.axf" ; arm-none-eabi-objcopy -v -O binary "rt1060-evk-xpresso-baremetal-builtin.axf" "rt1060-evk-xpresso-baremetal-builtin.bin" ; # checksum -p -d "rt1060-evk-xpresso-baremetal-builtin.bin"
text data bss dec hex filename
134268 756 21092 156116 261d4 rt1060-evk-xpresso-baremetal-builtin.axf
copy from `rt1060-evk-xpresso-baremetal-builtin.axf' [elf32-littlearm] to `rt1060-evk-xpresso-baremetal-builtin.bin' [binary]

16:54:59 Build Finished. 0 errors, 0 warnings. (took 2s.794ms)

Mcuxpressoide:
JVM terminated. Exit code=1
/usr/local/mcuxpressoide-11.8.1_1197/ide//plugins/org.eclipse.justj.openjdk.hotspot.jre.full.linux.x86_64_17.0.5.v20221102-0933/jre/bin/java
-Dosgi.requiredJavaVersion=17
-Xms256m
-Xmx3072m
-Djava.net.useSystemProxies=true
-Dnashorn.args=--language=es6
-jar /usr/local/mcuxpressoide-11.8.1_1197/ide//plugins/org.eclipse.equinox.launcher_1.6.400.v20210924-0641.jar
-os linux
-ws gtk
-arch x86_64
-launcher /usr/local/mcuxpressoide-11.8.1_1197/ide/mcuxpressoide
-name Mcuxpressoide
--launcher.library /usr/local/mcuxpressoide-11.8.1_1197/ide//plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.2.700.v20221108-1024/eclipse_11801.so
-startup /usr/local/mcuxpressoide-11.8.1_1197/ide//plugins/org.eclipse.equinox.launcher_1.6.400.v20210924-0641.jar
--launcher.overrideVmargs
-exitdata 0
-application org.eclipse.cdt.managedbuilder.core.headlessbuild
-data workspace
-import ../../examples/nxp/rt1060-evk-xpresso-baremetal-builtin
-cleanBuild rt1060-evk-xpresso-baremetal-builtin/Debug
-vm /usr/local/mcuxpressoide-11.8.1_1197/ide//plugins/org.eclipse.justj.openjdk.hotspot.jre.full.linux.x86_64_17.0.5.v20221102-0933/jre/bin/java
-vmargs
-Dosgi.requiredJavaVersion=17
-Xms256m
-Xmx3072m
-Djava.net.useSystemProxies=true
-Dnashorn.args=--language=es6
-jar /usr/local/mcuxpressoide-11.8.1_1197/ide//plugins/org.eclipse.equinox.launcher_1.6.400.v20210924-0641.jar 

log file:

!SESSION 2024-01-05 16:54:35.627 -----------------------------------------------
eclipse.buildId=unknown
java.version=17.0.5
java.vendor=Eclipse Adoptium
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
Framework arguments: -application org.eclipse.cdt.managedbuilder.core.headlessbuild -import ../../examples/nxp/rt1060-evk-xpresso-baremetal-builtin -cleanBuild rt1060-evk-xpresso-baremetal-builtin/Debug
Command-line arguments: -os linux -ws gtk -arch x86_64 -application org.eclipse.cdt.managedbuilder.core.headlessbuild -data workspace -import ../../examples/nxp/rt1060-evk-xpresso-baremetal-builtin -cleanBuild rt1060-evk-xpresso-baremetal-builtin/Debug

!ENTRY com.nxp.mcuxpresso.core.datamodels 1 0 2024-01-05 16:54:44.206
!MESSAGE Recreating part support. No part support available.

!ENTRY com.crt.log 1 0 2024-01-05 16:54:44.322
!MESSAGE Unable to find part support for NXP MIMXRT1062xxxxB in project rt1060-evk-xpresso-baremetal-builtin Resetting to generic part for core cm7.

!ENTRY com.crt.log 4 -1 2024-01-05 16:54:56.942
!MESSAGE Exception
!STACK 0
java.lang.Exception: java.lang.InterruptedException
at com.crt.utils.general.Reporter.log(Reporter.java:591)
at com.crt.utils.general.SafeUIJobWithProgress.run(SafeUIJobWithProgress.java:92)
at com.crt.utils.general.Reporter.showMessageBox(Reporter.java:920)
at com.crt.advproject.linker.CreateLinkerScript2.checkTargetConfig(CreateLinkerScript2.java:740)
at com.crt.advproject.linker.CreateLinkerScript2.buildScripts(CreateLinkerScript2.java:681)
at com.crt.advproject.custom.CRTLinkerScriptGenerator.generateLinkerScript(CRTLinkerScriptGenerator.java:55)
at com.crt.advproject.custom.CRTLinkerCmdLineInfo.generateLinkerScript(CRTLinkerCmdLineInfo.java:183)
at com.crt.advproject.custom.CRTLinkerCmdLineInfo.massageCmdLine(CRTLinkerCmdLineInfo.java:189)
at com.crt.advproject.custom.CRTManagedCmdLineInfo.getCommandLine(CRTManagedCmdLineInfo.java:53)
at org.eclipse.cdt.managedbuilder.makegen.gnu2.GnuMakefileGenerator.addRuleForTool(GnuMakefileGenerator.java:1768)
at org.eclipse.cdt.managedbuilder.makegen.gnu2.GnuMakefileGenerator.addTargetsRules(GnuMakefileGenerator.java:1545)
at org.eclipse.cdt.managedbuilder.makegen.gnu2.GnuMakefileGenerator.addTargets(GnuMakefileGenerator.java:1467)
at org.eclipse.cdt.managedbuilder.makegen.gnu2.GnuMakefileGenerator.populateTopMakefile(GnuMakefileGenerator.java:1136)
at org.eclipse.cdt.managedbuilder.makegen.gnu2.GnuMakefileGenerator.regenerateMakefiles(GnuMakefileGenerator.java:977)
at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.performMakefileGeneration(CommonBuilder.java:1024)
at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.performPrebuildGeneration(CommonBuilder.java:887)
at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.build(CommonBuilder.java:767)
at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.build(CommonBuilder.java:524)
at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.build(CommonBuilder.java:466)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:1020)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:247)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:419)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:618)
at org.eclipse.core.internal.resources.Project$1.run(Project.java:571)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2380)
at org.eclipse.core.internal.resources.Project.internalBuild(Project.java:609)
at org.eclipse.core.internal.resources.Project.build(Project.java:129)
at org.eclipse.cdt.managedbuilder.core.ManagedBuildManager$2.buildProject(ManagedBuildManager.java:4492)
at org.eclipse.cdt.managedbuilder.core.ManagedBuildManager$2.run(ManagedBuildManager.java:4469)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2380)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2400)
at org.eclipse.cdt.managedbuilder.core.ManagedBuildManager.buildConfigurations(ManagedBuildManager.java:4501)
at org.eclipse.cdt.managedbuilder.core.ManagedBuildManager.buildConfigurations(ManagedBuildManager.java:4381)
at org.eclipse.cdt.managedbuilder.internal.core.HeadlessBuilder.buildConfigurations(HeadlessBuilder.java:322)
at org.eclipse.cdt.managedbuilder.internal.core.HeadlessBuilder.start(HeadlessBuilder.java:710)
at org.eclipse.cdt.managedbuilder.internal.headlessbuilderapp.HeadlessBuilderWrapper.start(HeadlessBuilderWrapper.java:131)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:136)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:402)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:659)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:596)
at org.eclipse.equinox.launcher.Main.run(Main.java:1467)
at org.eclipse.equinox.launcher.Main.main(Main.java:1440)
Caused by: java.lang.InterruptedException
at com.crt.utils.general.SafeUIJobWithProgress.waitForResult(SafeUIJobWithProgress.java:77)
at com.crt.utils.general.SafeUIJobWithProgress.run(SafeUIJobWithProgress.java:87)
... 48 more

!ENTRY com.crt.advproject 4 -1 2024-01-05 16:54:56.946
!MESSAGE Missing MCU setting for rt1060-evk-xpresso-baremetal-builtin
Use Project->Properties->MCU Settings to correct
No linker script created

This is almost the very same setup we use to build with ST's STM32CubeIDE

This may be similar to https://community.nxp.com/t5/MCUXpresso-General/MCUXpresso-command-line-build-in-linux-fails/td-p/83... which has never been answered back.

[lpcxpresso_supp]

!ENTRY com.nxp.mcuxpresso.core.datamodels 1 0 2024-01-05 16:54:44.206
!MESSAGE Recreating part support. No part support available.

!ENTRY com.crt.log 1 0 2024-01-05 16:54:44.322
!MESSAGE Unable to find part support for NXP MIMXRT1062xxxxB in project rt1060-evk-xpresso-baremetal-builtin Resetting to generic part for core cm7.

According to the logs you sent, the IDE is unable to find the required SDK that is associated to your project. If you're saying that only the docker image is problematic, I think that you're really missing the SDK in that setup.

See section 4.2.8 from User Guide that shows you how to configure paths for SDKs lookup. The SDKs you manually installed via GUI version, are installed in the path listed on the Preference page. But note that the preferences are workspace-specific, so changing it in your CI/CD environment might not be possible. My suggestion is to manually copy the SDK zip package where the IDE expects it to be (usually <user_home>/mcuxpresso/02/SDKPackages). When this is fixed, you should no longer see the above messages in the log - and hopefully, JVM exits with success code.

Regards,
MCUXpresso IDE Support

[scaprile]

Is it possible to just run an Eclipse build without requiring the SDK and all that, as other vendors do ?
This is Linux, there is only executable here, there is no 'c' ending executable as the command line UG says (which apparently is for Windows only ?)

[lpcxpresso_supp]

Is it possible to just run an Eclipse build without requiring the SDK and all that, as other vendors do ?

From a build perspective, it is possible and you seem to be able to do it as well. If you're not using linked source files from within the SDK, you should be fine. My recommendation to install the SDK came as a potential fix for the unexpected JVM exit code. Maybe something else is making Eclipse exit with a non-zero code.

We'll try a similar use case on our side and get back with the result once we have it. 

Regards,
MCUXpresso IDE Support

[scaprile]

Thx, for some reason this post, written AFTER, was put above the one I wrote BEFORE... where I explain that adding the SDK solves that JVM issue within certain constraints that won't apply to our setup.

[lpcxpresso_supp]

We reproduced the behavior you described. Without the required SDK being installed, the IDE is not able to regenerate the linker scripts. Logged an internal ticket to track this and we'll plan it for the next release.

Regards,
MCUXpresso IDE Support

[scaprile]

Thanks.
In fact, we preserve the linker scripts in our repo, so Eclipse headless building is possible, it works, and there is no need to rebuild those scripts. This also happens with ST IDE, though they keep their scripts in the main directory instead of the target directory, so Debug, Release, can be safely ignored (and deleted) when committing.

The main issue, in my opinion, is not regenerating those linker scripts, they are fine as they are, but skipping extra SDK stuff when it has not been requested, so the JVM does not return an error and a make or bash script can receive a success return code and a CI/CD process can continue.

[scaprile]

Thank you for your reply.

The Docker image is the very same for both the development of examples and the headless build.

They were being run at different locations: developers develop examples, those are placed in a repository, then the examples are imported and headless built in a different workspace. There are no SDKs in the test installation, SDKs are downloaded by the developers and as far as I understand and my experience with other vendor's tools tell me, I don't see a reason to need the SDK. The project has been done, it is finished, all its files are in a directory, it just needs to be built, it has all that it needs there. In fact, seeing my logs, the project builds OK. Following your advice, I'm running the headless build on the same path where the SDKs are. In fact, I need to do the very same Docker invocation providing X11, otherwise it

No protocol specified
Unable to init server: Could not connect: Connection refused


!ENTRY org.eclipse.osgi 4 0 2024-01-10 14:21:08.602
!MESSAGE Application error
!STACK 1
org.eclipse.swt.SWTError: No more handles [gtk_init_check() failed]

Now it works.

This is not truly a headless build and is not suitable for a CI/CD pipeline, at least not for ours:

• There won't be any X11 support on our CI/CD runners.
• Requiring access to the SDK to make the tool happy means that we need to recreate a new Docker image every time we add support for a new part, or download the SDK on-demand every time we run the tests.

Addendum:
For some reason, MCUXpressoIDE insists in downloading the MIMXRT1060-EVKB SDK in the plugins folder, that is in the Docker image, instead of the expected path as you mentioned. Result is that the SDK is lost after closing the IDE. I manually copied it to the expected place.
The 1020 SDK had been downloaded with the former version, 11.8.0, and was found were expected. Hope I don't need to download any more SDKs.

Regards

@lpcxpresso_supp 

[ZhangJennie]

Hi scaprile 

For commandline headless build, I suggest you trying the solution in this article. See how it works. 

https://mcuoneclipse.com/2017/08/03/building-eclipse-and-mcuxpresso-ide-projects-from-the-command-li...

Have a nice day,

Jun Zhang

[scaprile]

Can you please take the time to actually read the issue and see that I already know what I need to do, have done that, and I'm reporting a detailed issue, before sending me to some wannabe-enthusiast-oriented page that is 6 years old, showing a copy of what can be read by just typing a command ? Please.

Did you read that we already have a scheme like this working with STM32CubeIDE, which btw also happens to use Eclipse and we know what we are doing ?

Cesanta is an NXP partner; could you be so kind to forward this to someone who is able to debug those Java virtual machine errors and help with what is needed with this setup ? Thank you.

[ZhangJennie]

What's your MCUCpresso IDE version?

The IDE 11.8.1  is tested under Ubuntu 20.04 without docker.To identify if the problem is caused by docker relate java issue, did you ever test if it works under Ubuntu 20.04 without docker?

[scaprile]

> What's your MCUCpresso IDE version?

Mcuxpressoide:
JVM terminated. Exit code=1
/usr/local/mcuxpressoide-11.8.1_1197/ide//plugins/org.eclipse.justj.openjdk.hotspot.jre.full.linux.x86_64_17.0.5.v20221102-0933/jre/bin/java

 > The IDE 11.8.1 is tested under Ubuntu 20.04 without docker.To identify if the problem is caused by docker relate java issue, did you ever test if it works under Ubuntu 20.04 without docker?

The reasons I'm using Docker are:
1- I don't run Ubuntu 20.04
2- My CI/CD provider will run it on a Docker container using Ubuntu 20.04 or 22.04.

I trust you tested it and it works, there is no reason for me to test it again; if it doesn't work inside a container is because something is missing in my image or my setup, then that is the reason why I'm asking for your support, as I've already satisfied the list of dependencies and have the IDE running with its graphic interface in my 20.04 image and just need it to run with the command line in order to integrate it in our CI/CD pipeline. This is the very same image I use to develop example code, just using command line now instead of the GUI.