macOS build on the factory failed with "No Java runtime present ... Alarm clock: 14"

Development
1

The build failed reporting error like the following:

Unable to find any JVMs matching version "(null)".
No Java runtime present, try --request to install.
Unable to find any JVMs matching version "(null)".
No Java runtime present, try --request to install.
make[6]: *** [all] Alarm clock: 14
make[5]: *** [SimpleITK-prefix/src/SimpleITK-stamp/SimpleITK-build] Error 2
make[4]: *** [CMakeFiles/SimpleITK.dir/all] Error 2
make[3]: *** [all] Error 2

Short story: This should soon be fixed in r27081

more details …

It turns out that on macOS, despite of not having Java installed, there are stub executables that all return a message like the following:

No Java runtime present, requesting install.

I suspect that a popup dialog asking the user to install java was shown (using a background process) and in that situation … no user clicked and it timed out reporting. This would explain the Alarm clock: 14

This was confirm connecting using VNC (instead of SSH):

image

I also suspect this is due to the following call in SimpleITK:

Indeed, both JNI and JAVA CMake modules are doing a call to java_home executable during the configuration process:

To avoid call to this executable, I even looked into removing the symlink from /usr/lib, but doesn’t seem possible without restarting the machine (even with root access). See macos - Operation Not Permitted when on root - El Capitan (rootless disabled) - Stack Overflow

To address this for all developers, we will update the SimpleITK external project to explicitly mark Java and JNI as not found, This can be done using this option: CMAKE_DISABLE_FIND_PACKAGE_<PackageName> — CMake 3.29.3 Documentation

List of executable with stub is the following:

$ for cmd in $(ls /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/); do 
  ($cmd 2>&1 | grep "No Java runtime present" > /dev/null) && echo $(which $cmd) || true;
done
/usr/bin/appletviewer
/usr/bin/apt
/usr/bin/extcheck
/usr/bin/idlj
/usr/bin/jar
/usr/bin/jarsigner
/usr/bin/java
/usr/bin/javac
/usr/bin/javadoc
/usr/bin/javah
/usr/bin/javap
/usr/bin/jcmd
/usr/bin/jconsole
/usr/bin/jdb
/usr/bin/jdeps
/usr/bin/jhat
/usr/bin/jinfo
/usr/bin/jjs
/usr/bin/jmap
/usr/bin/jmc
/usr/bin/jps
/usr/bin/jrunscript
/usr/bin/jsadebugd
/usr/bin/jstack
/usr/bin/jstat
/usr/bin/jstatd
/usr/bin/jvisualvm
/usr/bin/keytool
/usr/bin/native2ascii
/usr/bin/orbd
/usr/bin/pack200
/usr/bin/policytool
/usr/bin/rmic
/usr/bin/rmid
/usr/bin/rmiregistry
/usr/bin/schemagen
/usr/bin/serialver
/usr/bin/servertool
/usr/bin/tnameserv
/usr/bin/unpack200
/usr/bin/wsgen
/usr/bin/wsimport
/usr/bin/xjc

And the only one that do not out the message are:

$ for cmd in $(ls /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/); do 
  ($cmd 2>&1 | grep "No Java runtime present" > /dev/null) || echo $(which $cmd);
done

javaws

and the one that is not in the path is java_home and it outputs:

Unable to find any JVMs matching version "(null)".
No Java runtime present, try --request to install.
2

After testing locally, that last fix didn’t work out.

A different approach along with a patch to the upstream project was implemented. See r27082 and https://github.com/SimpleITK/SimpleITK/pull/424

The build on macOS has been manually re-triggered using the following command:

run_ctest_with_disable_clean=TRUE \
run_ctest_with_update=FALSE \
/Volumes/Dashboards/DashboardScripts/factory-south-macos.sh > /Volumes/Dashboards/Logs/factory-south-macos.log

Since this is a nightly build, the existing report on CDash will be updated and any additional errors will be appended to the report.

For reference:

    COMP: Update SimpleITK to effectively avoid unwanted find_package calls
    
    This commit reverts the approach implemented in the previous commit. It
    failed because SimpleITK has a superbuild structure and the CMAKE_DISABLE_FIND_PACKAGE_*
    options are not propagated down to the inner build.
    
    Instead, a patch improving the handling of SimpleITK wrapping options
    has been proposed to the upstream project (and in the mean time integrated
    in our Slicer fork).
    
    The implemented solution consists in avoiding the call to "find_package()"
    if the corresponding WRAP_<languageName> option has explicitly been set or
    if WRAP_DEFAULT is set to OFF.
    Indeed, there is no need to do these call to find an appropriate default value
    for the option since the user (in this case Slicer build system) explicitly
    set of value of for the options (eiter directly or by setting WRAP_DEFAULT).
    
    See https://github.com/SimpleITK/SimpleITK/pull/424
    
    List of changes:
    
    $ git shortlog 67872f8..7572225 --no-merges
    Jean-Christophe Fillion-Robin (1):
          sitkLanguageOptions: Improve setting of default value for wrap options
1 Like
3

To follow up on this, by working with the maintainer of SimpleITK (thanks @blowekamp), issue has been addressed in the upstream project:

4

I have noticed that extension for stable are not being build anymore for Mac since a couple of days. Can you confirm this? can this be fixed?

Regards,

Fausto

5

Hi @fausto_milletari,

It should be back in order. See http://slicer.cdash.org/index.php?project=Slicer4&filtercount=1&showfilters=1&field1=site&compare1=63&value1=factory-macos.kitware

Also, crontab associated with this build machine is now backed up. See:

1 Like
6

now it’s all good. many thanks!