[JAVA-4808] CSFLE fails with SIGSEGV on macos M1 Created: 09/Nov/22  Updated: 27/Oct/23  Resolved: 11/Nov/22

Status: Closed
Project: Java Driver
Component/s: Client Side Encryption
Affects Version/s: 4.7.2
Fix Version/s: None

Type: Question Priority: Unknown
Reporter: Peter Schulz Assignee: Jeffrey Yemin
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File hs_err_pid93190.log    

 Description   

Summary

I tried to run the MakeDataKey.java example on macos 12.6 (M1) with various open JDKs against a MongoDB CE server. It fails with a SIGSEGV when clientEncryption.createDataKey is called, see log below, full log attached.

Envirionment:

  • OS: macOS 12.6 (M1/ARM64)
  • JDKs (with ARM64 support)
    • 11.0.17 Bellsoft
    • 11.0.17 Microsoft
  • MongoDB Driver: 4.7.2 (also tried with mongodb-crypt 1.6.1)
  • MongoDB Server: 6.0.2 CE via official docker image

How to Reproduce

  • Run MakeDataKey.main() in an environment as described above.

Additional Background

I ran the same code on macOS 12.6 (Intel) and it works.

Log Excerpt

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000103e54744, pid=93190, tid=10243
#
# JRE version: OpenJDK Runtime Environment (11.0.17+7) (build 11.0.17+7-LTS)
# Java VM: OpenJDK 64-Bit Server VM (11.0.17+7-LTS, mixed mode, tiered, compressed oops, g1 gc, bsd-aarch64)
# Problematic frame:
# V  [libjvm.dylib+0x37c744]  jni_CallBooleanMethod+0x130
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   https://bell-sw.com/support
#
 
---------------  S U M M A R Y ------------
 
Command Line: -Dvisualvm.id=1160185610076958 -javaagent:/Applications/IntelliJ IDEA.app/Contents/lib/idea_rt.jar=55573:/Applications/IntelliJ IDEA.app/Contents/bin -Dfile.encoding=UTF-8 example.MakeDataKey
 
Host: MacBookPro18,2 arm64 1 MHz, 10 cores, 64G, Darwin 21.6.0
Time: Wed Nov  9 11:55:58 2022 CET elapsed time: 1.617464 seconds (0d 0h 0m 1s)
 
---------------  T H R E A D  ---------------
 
Current thread (0x000000013200e800):  JavaThread "main" [_thread_in_vm, id=10243, stack(0x000000016d268000,0x000000016d46b000)]
 
Stack: [0x000000016d268000,0x000000016d46b000],  sp=0x000000016d4695d0,  free space=2053k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x37c744]  jni_CallBooleanMethod+0x130
C  [jna1423610536563489332.tmp+0x10044]  ffi_prep_closure_loc+0x198c
C  [jna1423610536563489332.tmp+0xe668]  ffi_call+0x500
C  [jna1423610536563489332.tmp+0xd550]  JNA_callback_dispose+0x4d8
C  [jna1423610536563489332.tmp+0xccc4]  create_callback+0x7a0
C  [jna1423610536563489332.tmp+0xeb30]  ffi_prep_closure_loc+0x478
C  [jna1423610536563489332.tmp+0x101b4]  ffi_prep_closure_loc+0x1afc
C  [jna1265019451281734799.tmp+0x7824]  _mongocrypt_random+0x64
C  [jna1265019451281734799.tmp+0x8ed4]  mongocrypt_ctx_datakey_init+0xe4
C  [jna1423610536563489332.tmp+0x10044]  ffi_prep_closure_loc+0x198c
C  [jna1423610536563489332.tmp+0xe668]  ffi_call+0x500
C  [jna1423610536563489332.tmp+0xb268]  Java_com_sun_jna_Native_registerMethod+0xe44
C  [jna1423610536563489332.tmp+0xeb30]  ffi_prep_closure_loc+0x478
C  [jna1423610536563489332.tmp+0x101b4]  ffi_prep_closure_loc+0x1afc
j  com.mongodb.crypt.capi.CAPI.mongocrypt_ctx_datakey_init(Lcom/mongodb/crypt/capi/CAPI$mongocrypt_ctx_t;)Z+0
j  com.mongodb.crypt.capi.MongoCryptImpl.createDataKeyContext(Ljava/lang/String;Lcom/mongodb/crypt/capi/MongoDataKeyOptions;)Lcom/mongodb/crypt/capi/MongoCryptContext;+348
j  com.mongodb.client.internal.Crypt.createDataKey(Ljava/lang/String;Lcom/mongodb/client/model/vault/DataKeyOptions;)Lorg/bson/BsonDocument;+46
j  com.mongodb.client.internal.ClientEncryptionImpl.createDataKey(Ljava/lang/String;Lcom/mongodb/client/model/vault/DataKeyOptions;)Lorg/bson/BsonBinary;+6
j  example.MakeDataKey.main([Ljava/lang/String;)V+405
v  ~StubRoutines::call_stub
V  [libjvm.dylib+0x335a14]  _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP6Thread+0x2dc
V  [libjvm.dylib+0x384bc0]  _ZL17jni_invoke_staticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread+0x10c
V  [libjvm.dylib+0x38878c]  jni_CallStaticVoidMethod+0x17c
C  [libjli.dylib+0x5a14]  JavaMain+0xb34
C  [libjli.dylib+0x7b38]  ThreadJavaMain+0xc
C  [libsystem_pthread.dylib+0x726c]  _pthread_start+0x94 



 Comments   
Comment by Peter Schulz [ 11/Nov/22 ]

Thank you Jeffrey!

It turns out, that JNA 5.8.0 was in still in class path due to to a maven artifact resolution issue:
org.testcontainers:testcontainers has a transitive dependency on com.github.docker-java:docker-java-transport that in turn still requests JNA 5.8.0. 

You may close the issue.

Comment by Jeffrey Yemin [ 10/Nov/22 ]

Glad to hear you discovered the problem.

We updated the JNA dependency of mongodb-crypt to 5.11.0 here, which I believe is sufficient (but please let us know if you've found otherwise).

Can you think of anything else we should do? If not, I'll close this issue.

Comment by Peter Schulz [ 10/Nov/22 ]

Apparently this can be fixed by bumping the jna dependency from 5.8.0 }}to {{{}5.12.1. At least it works on my machine. So as a workaround declare the following in your POM:

<dependencyManagement>
    <dependency>
      <groupId>net.java.dev.jna</groupId>
      <artifactId>jna</artifactId>
      <version>5.12.1</version>
    </dependency>
  </dependencies>
</dependencyManagement> 

 

 

Generated at Thu Feb 08 09:03:01 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.