Jansi crashes JVM

[bmuschko]

Gradle is bundled with Jansi 1.14 and sets the system property library.jansi.path to avoid extracting its native libraries to a temp directory avoid problems with system that don't give execute permissions to temp directories. If a build script invokes the Java compiler then compilation is performed in the same JVM as Gradle. The user provides an annotation processor that internally uses an older version of Jansi (I believe 1.11). It seems that Jansi uses the wrong native libraries and crashes the JVM. If Java compilation is done in a forked JVM process then all is good.

You can find an excerpt here (full core dump):

j  org.fusesource.jansi.internal.CLibrary.init()V+0
j  org.fusesource.jansi.internal.CLibrary.<clinit>()V+21
v  ~StubRoutines::call_stub
j  org.fusesource.jansi.AnsiConsole.wrapOutputStream(Ljava/io/OutputStream;)Ljava/io/OutputStream;+61
j  org.fusesource.jansi.AnsiConsole.<clinit>()V+13
v  ~StubRoutines::call_stub
j  com.dslplatform.compiler.client.Context.<init>()V+1
j  com.dslplatform.json.AnnotationCompiler$DslContext.<init>(Ljavax/annotation/processing/Messager;Lcom/dslplatform/json/AnnotationCompiler$LogLevel;)V+1

The original issue was reported here. It also describes the affected operating systems. This integration test might help with understanding the issue.

[bmuschko]

@chirino Following up on this issue. Did someone have a chance to look into it?

[udalov]

We also encountered this issue in Kotlin: https://youtrack.jetbrains.com/issue/KT-17031. Would be nice to know if there are plans to investigate into it. Thanks!

[gnodet]

I'm willing to investigate this issue, but I'm not sure I can see any way out. It seems to me that the problem comes from trying to load the same native library in 2 different versions, and that's definitely not supported by the JVM afaik.

[alexvas]

Just in case anyone else encounter the problem (as me with Gradle 7.3.3):
using strict version of Jansi library (1.18 -- same as in Gradle in my case), here is the fix:

        api("org.fusesource.jansi:jansi") {
            // old version here otherwise there will be a core dump
            version {
                strictly("1.18")
            }
        }

[gnodet]

Could it be related to #216 ?

[alexvas]

Could it be related to #216 ?

I do not think so. It is more or less original issue. Here is a problem thread dump:

Stack: [0x00007f7880d48000,0x00007f7880e49000],  sp=0x00007f7880e45930,  free space=1014k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x7051b7]  jni_SetStaticIntField+0x77
C  [libjansi.so+0x1b56]  Java_org_fusesource_jansi_internal_CLibrary_init+0x36

[error occurred during error reporting (printing native stack), id 0xb]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.fusesource.jansi.internal.CLibrary.init()V+0
j  org.fusesource.jansi.internal.CLibrary.<clinit>()V+27
v  ~StubRoutines::call_stub
j  org.fusesource.jansi.AnsiConsole.ansiStream(Z)Lorg/fusesource/jansi/AnsiPrintStream;+111
j  org.fusesource.jansi.AnsiConsole.initStreams()V+26
j  org.fusesource.jansi.AnsiConsole.systemInstall()V+32
j  io.ktor.features.CallLogging$Configuration.colored(Lio/ktor/http/HttpStatusCode;)Ljava/lang/String;+29

It is the same "trying to load the same native library in 2 different versions" you stated above:

1. gradle running in console -> loading jansi v.1.18
2. gradle running in console -> running integration test -> starting ktor -> loading jansi v.2.4.0

So in my case the fix is to downgrade jansi version for the whole project.

[anthonywww]

Seeing this in 2.4.0 via Maven

Current thread (0x000002bd118cdee0):  JavaThread "main" [_thread_in_native, id=15216, stack(0x000000c2c1900000,0x000000c2c1a00000)]

Stack: [0x000000c2c1900000,0x000000c2c1a00000],  sp=0x000000c2c19fea90,  free space=1018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [jansi-2.4.0-92d5f3415620e3c7-jansi.dll+0x29bf]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.fusesource.jansi.internal.CLibrary.isatty(I)I+0
j  org.fusesource.jansi.AnsiConsole.ansiStream(Z)Lorg/fusesource/jansi/AnsiPrintStream;+62
j  org.fusesource.jansi.AnsiConsole.initStreams()V+7
j  org.fusesource.jansi.AnsiConsole.systemInstall()V+15
j  <redacted>.main([Ljava/lang/String;)V+0
v  ~StubRoutines::call_stub

siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), writing address 0x0000000000000000


Register to memory mapping:

RIP=0x0000000069ac29bf jansi-2.4.0-92d5f3415620e3c7-jansi.dll
RAX=0x0 is NULL
RBX={method} {0x000002bd3441e110} 'isatty' '(I)I' in 'org/fusesource/jansi/internal/CLibrary'
RCX=0x0 is NULL
RDX=0x0000000069ac6362 jansi-2.4.0-92d5f3415620e3c7-jansi.dll
RSP=0x000000c2c19fea90 is pointing into the stack for thread: 0x000002bd118cdee0
RBP=0x000000c2c19fef58 is pointing into the stack for thread: 0x000002bd118cdee0
RSI=0x0 is NULL
RDI=0x000002bd3403a1a0 is pointing into metadata
R8 =0x000000c2c19fea88 is pointing into the stack for thread: 0x000002bd118cdee0
R9 =0x000000c2c19fef58 is pointing into the stack for thread: 0x000002bd118cdee0
R10=0x0 is NULL
R11=0x0000000000000246 is an unknown value
R12=0x0 is NULL
R13={method} {0x000002bd3441e110} 'isatty' '(I)I' in 'org/fusesource/jansi/internal/CLibrary'
R14=0x000000c2c19fef78 is pointing into the stack for thread: 0x000002bd118cdee0
R15=0x000002bd118cdee0 is a thread

[gnodet]

Unfortunately, there's no way to load two native libraries in different versions, so the workaround is to force the version of jansi used.