[3.0.19] JVM crash on Mac Arm after every controls().stop()

[avently]

Hello. First of all, thank you for the library. Using it in production for around a year.

Couple of weeks ago Gradle started to give an error while building a project because for some reason it couldn't find a jna dependency. This is how it was in build files:

implementation("uk.co.caprica:vlcj:4.8.2")

implementation("net.java.dev.jna:jna:5.14.0")

I remember that this JNA dependency was needed to make the player working, so it was left in codebase as is. But since Gradle started to give the error, I removed JNA dependency and the player still worked correctly... but not on Mac Arm. On Mac Arm every call to controls().stop() crashes JVM with the following stacktrace:

Current thread (0x000000014e06b000):  JavaThread "AWT-EventQueue-0"        [_thread_in_vm, id=74499, stack(0x000000032e894000,0x000000032ea97000) (2060K)]

Stack: [0x000000032e894000,0x000000032ea97000],  sp=0x000000032ea94a60,  free space=2050k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x526ac8]  jni_CallVoidMethod+0xd0
C  [jna18438429294403318043.tmp+0x1004c]  ffi_prep_closure_loc+0x16cc
C  [jna18438429294403318043.tmp+0xe930]  ffi_call+0x4d0
C  [jna18438429294403318043.tmp+0xd7a4]  JNA_callback_dispose+0x540
C  [jna18438429294403318043.tmp+0xceb0]  create_callback+0x824
C  [jna18438429294403318043.tmp+0xedf8]  ffi_prep_closure_loc+0x478
C  [jna18438429294403318043.tmp+0x101d4]  ffi_prep_closure_loc+0x1854
C  [libvlc.dylib+0x7ec8]  libvlc_event_send+0x68
C  [jna18438429294403318043.tmp+0xe930]  ffi_call+0x4d0
C  [jna18438429294403318043.tmp+0xb338]  Java_com_sun_jna_Native_registerMethod+0xe8c
C  [jna18438429294403318043.tmp+0xedf8]  ffi_prep_closure_loc+0x478
C  [jna18438429294403318043.tmp+0x101d4]  ffi_prep_closure_loc+0x1854
j  uk.co.caprica.vlcj.binding.lib.LibVlc.libvlc_media_player_stop(Luk/co/caprica/vlcj/binding/internal/libvlc_media_player_t;)V+0
j  uk.co.caprica.vlcj.player.base.ControlsApi.stop()V+4
j  chat.simplex.common.platform.RecAndPlay_desktopKt.stop(Luk/co/caprica/vlcj/player/base/MediaPlayer;)V+10
j  chat.simplex.common.platform.AudioPlayer.start(Lchat/simplex/common/model/CryptoFile;ZLjava/lang/Integer;Lkotlin/jvm/functions/Function2;)Ljava/lang/Integer;+150
j  chat.simplex.common.platform.AudioPlayer.play(Lchat/simplex/common/model/CryptoFile;Landroidx/compose/runtime/MutableState;Landroidx/compose/runtime/MutableState;Landroidx/compose/runtime/MutableState;ZZLkotlin/coroutines/Continuation;)Ljava/lang/Object;+67

I use the same VLC build (build was made by me) from previous year, nothing changed in this aspect. JVM also crashes if I don't stop but .prepare() another media. Not sure what can be the reason for such problem. I also compiled the latest code from 3.0.x branch of VLC on Intet Mac and got a freeze instead of crash.

I think the problem cannot be in the library but since you have a lot of experience, maybe you can give an advice and point into the right direction? What can be the cause and how to make it working again without using that broken JNA dependency?

P.s. all logic around the player is inside this file: https://github.com/simplex-chat/simplex-chat/blob/stable/apps/multiplatform/common/src/desktopMain/kotlin/chat/simplex/common/platform/RecAndPlay.desktop.kt#L27

[caprica]

Not sure.

For context...

vlcj 4.8.2 uses JNA 5.12.1 which is why you previously needed the explicit JNA dependency to override it to 5.14.0 (the latest as of right now).

vlcj 4.8.3 is the latest release and this version uses JNA 5.14.0.

For the crash on stop...

I can't tell anything from your JVM crashdump tbh. I can only suggest you very carefully check code and make sure you are holding hard references to all vlcj objects. This is something where I've seen the GC on Windows vs Linux work differently and code that worked on one platform would crash on another because the GC was more "aggressive".

There's potentially some issue with JNA on macOS ARM, but I have no real evidence to back that up.

[caprica]

It would be interesting if you have been able to build VLC yourself, that you added some log statements to the libvlc_media_player_stop method to see first if that function is actually called, and where in that function the crash is triggered (or not).

[caprica]

I have no Mac ARM hardware so I can't do any more.

[avently]

I can't tell anything from your JVM crashdump tbh. I can only suggest you very carefully check code and make sure you are holding hard references to all vlcj objects

I tried to NOT release any player instances and hold references forever, but still the same situation.

It would be interesting if you have been able to build VLC yourself, that you added some log statements to the libvlc_media_player_stop method to see first if that function is actually called, and where in that function the crash is triggered (or not).

I added logs to the VLC sources but I don't see anything in system out. I see that logs should be enabled in VLCJ, so not sure why no logs at all. How to enable them? I mean, libvlc_printerr or printf.

By the way, since the initial problem came from Gradle that couldn't sync dependencies, I fixed the problem with Gradle. I have dependency on jSystemThemeDetector which has dependencies on JNA libs. And somehow that fact prevented Gradle from sync correctly (after year without other visible factors). So I excluded all dependencies from group "net.java.dev.jna" for jSystemThemeDetector and included required dependencies by hand, now Gradle is happy and VLC works correctly on Intel and Arm.

Final list of deps:

implementation("com.github.Dansoftowner:jSystemThemeDetector:3.8") {
  exclude("net.java.dev.jna")
}
// For jSystemThemeDetector only
implementation("net.java.dev.jna:jna-platform:5.14.0")

implementation("uk.co.caprica:vlcj:4.8.3")
implementation("net.java.dev.jna:jna:5.14.0")

BUT it works only using old build of VLC (3.0.19) and still freezes on Intel Mac with the latest code from 3.0.x branch. So logging would really help in this case:)

[caprica]

So there is no problem with vlcj on macOS on ARM now that you have a correct JNA dependency, right?

Your other problem is for VLC?

[avently]

So there is no problem with vlcj on macOS on ARM now that you have a correct JNA dependency, right?

At least with old version of VLC, no problem. With the latest code from 3.0.x there is a freeze of thread with unknown reason for now. And it's probably unrelated to VLCJ anyway

[avently]

So if you want, we can close the issue. But I still need to debug looks like in order to get logs

[caprica]

Feel free to post an update if vlcj is still implicated after your debugging.