Tests of examples/http-server failing

[redkhalil]

I have encountered this issue while following the example code and was able to reproduce it on the example code itself.

Testing started at 7:22 AM ...
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/Users/khalil.dowlut/Library/Caches/Coursier/v1/https/repo1.maven.org/maven2/ch/qos/logback/logback-classic/1.2.8/logback-classic-1.2.8.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/Users/khalil.dowlut/Library/Caches/Coursier/v1/https/repo1.maven.org/maven2/org/slf4j/slf4j-simple/1.7.30/slf4j-simple-1.7.30.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [ch.qos.logback.classic.util.ContextSelectorStaticBinder]



#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000010f58dce8, pid=41938, tid=0x0000000000009903
#
# JRE version: OpenJDK Runtime Environment (8.0_312) (build 1.8.0_312-bre_2021_10_20_23_15-b00)
# Java VM: OpenJDK 64-Bit Server VM (25.312-b00 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# V  [libjvm.dylib+0x545ce8]  Unsafe_SetByte+0x61
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /Users/some.user/temp/finatra/hs_err_pid41938.log
#
# If you would like to submit a bug report, please visit:
#   https://github.com/Homebrew/homebrew-core/issues
#

Process finished with exit code 134 (interrupted by signal 6: SIGABRT)

hs_err_pid41938.log

[redkhalil]

Hmm, strangely, I've switched from OpenJDK 1.8.0_312 to Oracle JDK 1.8.0_311 and the tests are passing (both the finatra test - above - and the tests for my service).
Can you advise if there is any dependency on a specific version of JDK. What are you guys using for development and production?

[mosesn]

That's odd. From looking at the stacktrace in your file, it looks like this might be a way that netty is incompatible with JDK 1.8.0_312? We use an older version of the JDK internally. I'm not sure what the github workflow for jdk8 uses. Would you mind filing a ticket with their project?

[cacoco]

@mosesn the CI action uses OpenJDK 1.8.0_332:

Run java -Xmx32m -version
openjdk version "1.8.0_332"
OpenJDK Runtime Environment (Zulu 8.62.0.19-CA-linux64) (build 1.8.0_332-b09)
OpenJDK 64-Bit Server VM (Zulu 8.62.0.19-CA-linux64) (build 25.332-b09, mixed mode)

The recommendation would be that users be at least on that version.

FWIW, this looks like a reported issue with Netty: netty/netty#12119 and potentially specific to the Homebrew version of JDK8 being installed.