random start-up crash

[robertd]

What is the bug or the crash?

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f3400176ae7, pid=1, tid=170
#
# JRE version: OpenJDK Runtime Environment Temurin-11.0.18+10 (11.0.18+10) (build 11.0.18+10)
# Java VM: OpenJDK 64-Bit Server VM Temurin-11.0.18+10 (11.0.18+10, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# J 1890 c2 java.lang.String.startsWith(Ljava/lang/String;I)Z java.base@11.0.18 (138 bytes) @ 0x00007f3400176ae7 [0x00007f3400176aa0+0x0000000000000047]
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /geoserver/core.1)
#
# An error report file with more information is saved as:
# /geoserver/hs_err_pid1.log
Compiled method (c1)   14156 2588       3       org.apache.catalina.loader.WebappClassLoaderBase::filter (474 bytes)
 total in heap  [0x00007f33f9120890,0x00007f33f91234c8] = 11320
 relocation     [0x00007f33f9120a08,0x00007f33f9120d98] = 912
 main code      [0x00007f33f9120da0,0x00007f33f9122ae0] = 7488
 stub code      [0x00007f33f9122ae0,0x00007f33f9122d50] = 624
 oops           [0x00007f33f9122d50,0x00007f33f9122d68] = 24
 metadata       [0x00007f33f9122d68,0x00007f33f9122db8] = 80
 scopes data    [0x00007f33f9122db8,0x00007f33f91230a0] = 744
 scopes pcs     [0x00007f33f91230a0,0x00007f33f91234a0] = 1024
 dependencies   [0x00007f33f91234a0,0x00007f33f91234a8] = 8
 nul chk table  [0x00007f33f91234a8,0x00007f33f91234c8] = 32
Could not load hsdis-amd64.so; library not loadable; PrintAssembly is disabled
#
# If you would like to submit a bug report, please visit:
#   https://github.com/adoptium/adoptium-support/issues
#

[error occurred during error reporting (), id 0xb, SIGSEGV (0xb) at pc=0x00007f3415f18941]

Steps to reproduce the issue

Random

Versions

2.24.1

Additional context

A quick google search pointed out that updating to JDK17 should fix this random issue.

[NyakudyaA]

@robertd We had not been updating the base image was because support for gdal-java has been dropped in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947960. GeoServer still relies on it https://docs.geoserver.org/stable/en/user/data/raster/gdal.html#linux-packages-and-setup but you are welcome to do a PR

[robertd]

@NyakudyaA It's getting harder and harder to run kartoza/geoserver in any of our environments due to the security scans flagging containers vulnerabilities.

@robertd We had not been updating the base image was because support for gdal-java has been dropped in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947960. GeoServer still relies on it https://docs.geoserver.org/stable/en/user/data/raster/gdal.html#linux-packages-and-setup but you are welcome to do a PR

How does one even start addressing this? Perhaps it's maybe time to drop gdal-java support for the sake of security? Thoughts?

[NyakudyaA]

@NyakudyaA It's getting harder and harder to run kartoza/geoserver in any of our environments due to the security scans flagging containers vulnerabilities.

@robertd We had not been updating the base image was because support for gdal-java has been dropped in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947960. GeoServer still relies on it https://docs.geoserver.org/stable/en/user/data/raster/gdal.html#linux-packages-and-setup but you are welcome to do a PR

How does one even start addressing this? Perhaps it's maybe time to drop gdal-java support for the sake of security? Thoughts?

@robertd I am not sure what security is being flagged, currently we have the following generated by trivy

And this has no relation to gdal. I think a better option would be to invest in building an image/latest with gdal-java and also taking into consideration that GeoServer doesn't use the very latest of tomcat as per the documentation

[robertd]

@NyakudyaA Our security team is using Acunetix for scanning. Here are the sanitized version of our latest reports.

I think a better option would be to invest in building an image/latest with gdal-java and also taking into consideration that GeoServer doesn't use the very latest of tomcat as per the documentation

Do you mind linking the GeoServer docs stating the tomcat version requirement? TIA.

[NyakudyaA]

@robertd The officially supported tomcat version is 11 while 17 also works but there is no guarantee that it will work.

If you do not need the gdal plugin to publish supported raster data, can you try to build using the latest tomcat and give us feedback. The only option to support this would be to introduce a new build Arg i.e ACTIVATE_GDAL=TRUE

which will control whether to install gdal-java and the rest of the image will work with or without gdal depending on the build Arg . If you feel this is a better option we can try this. Unfortunately Acunetix doesn't seem to be easily configurable to run with github action and hence we cannot use it unless if I didn't research enough

[NyakudyaA]

@robertd https://github.com/kartoza/docker-geoserver/pull/669 should fix running this with a new version of base image tomcat:$IMAGE_VERSION

[robertd]

Thanks @NyakudyaA, I'll give it a try.

[robertd]

@NyakudyaA I think that this solves only part of our problem. It's worth mentioning that most of our high vulnerabilities come from tomcat itself through 9.0.89-jdk11-temurin-focal. Since GeoServer doesn't work with tomcat:10.x (and most likely neither with tomcat:11.x too), I wonder if at least switching to 9.0.91-jdk11-temurin-focal or 9.0.91-jdk11-temurin-jammy would be compatible (or even worthwhile)... even though both of those versions have med vulnerabilities too.

Current: Focal - Ubuntu 20.04 LTS - 9.0.89-jdk11-temurin-focal

Focal - Ubuntu 20.04 LTS - 9.0.91-jdk11-temurin-focal

Jammy - 22.04 LTS - 9.0.91-jdk11-temurin-jammy

Also, just curious, can you tell my why is temurin base image being used over a standard (non-temurin) one?

[NyakudyaA]

@robertd With that PR you should be able to build the image locally with 9.0.91-jdk11-temurin-jammy because of the gdal plugin issue and we don't want to break compatibility for other users, but for the builds within this image I suggest we upgrade to 9.0.91-jdk11-temurin-focal, if you can do the PR, I will merge it.

What is the difference between temurin and an image without? If there is one better than the other to getting GeoServer to work, we should switch to that

[robertd]

if you can do the PR, I will merge it

https://github.com/kartoza/docker-geoserver/pull/671

What is the difference between temurin and an image without? If there is one better than the other to getting GeoServer to work, we should switch to that

I'm not a Java developer or anything :) , but I was just curious on why temurin was present.