SIGSEGV on callback with Linux and amd64

[seb30]

1. Version of JNA and related jars
   JNA 4.5.1

2. Version and vendor of the java virtual machine
   Oracle JDK 1.8.0_171_x64

3. Operating system
   Linux 4.9.0-6-amd64 Initial documentation in markdown format. #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux

4. System architecture (CPU type, bitness of the JVM)
   Oracle VM

5. Complete description of the problem
   The call of the callback throws a SIGSEGV exception and the JVM crashes. The command was sent properly to the device (acoustic feedback). The same code is working with Linux32 and Win64.

6. Steps to reproduce
   My project.

'#
'# A fatal error has been detected by the Java Runtime Environment:
'#
'# SIGSEGV (0xb) at pc=0x00007fe219622459, pid=21633, tid=0x00007fe21805c700
'#
'# JRE version: Java(TM) SE Runtime Environment (8.0_171-b11) (build 1.8.0_171-b11)
'# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.171-b11 mixed mode linux-amd64 compressed oops)
'# Problematic frame:
'# C [jna1739597464905679499.tmp+0xe459]
'#
'# Failed to write core dump. 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:
'# http://bugreport.java.com/bugreport/crash.jsp
'#

hs_err_pid21633.log

[matthiasblaesing]

Please provide the java bindings + C headers. I would wager, that parameters or return values are not bound correctly.

[seb30]

Is there a difference between Win and Linux?

public interface tDllResultHandlerGetTime extends Callback {
void resultHandlerGetTime(int sdwSeconds, Pointer rru4Handle, Pointer pTag);
}

typedef void (CALLCONVENTION tDllResultHandlerGetTime)(TsDWord sdwSeconds, RRU4 rru4Handle, void *pTag);

#define TsDWord int32_t
#define RRU4 void *

@matthiasblaesing Thank you for your help!

[matthiasblaesing]

The definition and the java binding look sane. One think that was discussed on the google group in the past was the GC of the callback. Have you ensured, that the callback you pass to native stays strongly referenced on the java side? If it is GCed, strange thinks could and will happen.

[seb30]

The callback is a private static final, so it shouldn't be GCed. The exception is also not "OutOfMemoryError".

[matthiasblaesing]

Is the project available somewhere, so that we could get to have a deeper look (ideally buildable in my environment)?

[seb30]

I can give you the code, but you can't run it useful without purchasing one of our devices 😁. Is a NetBeans project suitable for you?

[matthiasblaesing]

I'm not sure if I can see the problem just by looking at the code, but I'm willing to give it a try. I'm fine with a netbeans project, as I can't run it, I'll only read anyway :-)

[seb30]

@matthiasblaesing I've sent you a mail (mb*******@d*****-h****.eu) with the download link. Please handle it confidentially.

[matthiasblaesing]

@twall could you please have a look at PR #976?

I successfully ran @seb30 code and verified, that a 64 Bit C test programm and running the library on a 32 Bit JVM ran clean, but it failed on a 64 Bit VM.

I traced the segfault into the callback code of JNA and could pin-point it to happen in get_thread_storage after the AttachCurrentThread / AttachCurrentThreadAsDaemon calls in dispatch_callback. (see the PR for details).

The attachment fails (result code is JNI_ERR and the env pointer is a NULL pointer). I checked the stack size and it seems the problem, while the stacksize for the unittests was reported to be around 8 MB (matches ulimit), the call from the library that is bound here reports 65kB. I assume, that the JVM refuses to attach, if it determines there is not enough stack available for it.

I tried to come up with a unittest, but failed to make it reliable. For linux 64Bit I could make it work on my machine using the pthread functions to create a thread with a smaller stack, but that code failed for 32Bit, leaving me there with 8MB.

With the change from PR#976 I now get the "correct" result:

JNA: Can't attach native thread to VM for callback: -1

instead of the SEGFAULT.

[twall]

If the unit test works for the scenario which was originally failing, that's sufficient. It doesn't have to run on any other environment. This is a good change in general, the JNIEnv shouldn't be used at all without checking first.

…

On Sun, Jun 24, 2018 at 10:44 AM, Matthias Bläsing ***@***.*** > wrote: @twall <https://github.com/twall> could you please have a look at PR #976 <#976>? I successfully ran @seb30 <https://github.com/seb30> code and verified, that a 64 Bit C test programm and running the library on a 32 Bit JVM ran clean, but it failed on a 64 Bit VM. I traced the segfault into the callback code of JNA and could pin-point it to happen in get_thread_storage after the AttachCurrentThread / AttachCurrentThreadAsDaemon calls in dispatch_callback. (see the PR for details). The attachment fails (result code is JNI_ERR and the env pointer is a NULL pointer). I checked the stack size and it seems the problem, while the stacksize for the unittests was reported to be around 8 MB (matches ulimit), the call from the library that is bound here reports 65kB. I assume, that the JVM refuses to attach, if it determines there is not enough stack available for it. I tried to come up with a unittest, but failed to make it reliable. For linux 64Bit I could make it work on my machine using the pthread functions to create a thread with a smaller stack, but that code failed for 32Bit, leaving me there with 8MB. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#974 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAuMrWbt8uEQ4wIWg2oVtJQzWq4kRCbnks5t_6W_gaJpZM4Us4N5> .

[seb30]

@matthiasblaesing Thank you so much for your support! Increasing the stack size of the thread in the C lib fix my error.

[matthiasblaesing]

The referenced check for the success of the attachment of the JVM to the callback thread is now merged into master and 4.5.X.

[seb30]

Thank you so much @matthiasblaesing for all your support!