-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SIGSEGV on callback with Linux and amd64 #974
Comments
Please provide the java bindings + C headers. I would wager, that parameters or return values are not bound correctly. |
Is there a difference between Win and Linux? public interface tDllResultHandlerGetTime extends Callback { typedef void (CALLCONVENTION tDllResultHandlerGetTime)(TsDWord sdwSeconds, RRU4 rru4Handle, void *pTag); #define TsDWord int32_t @matthiasblaesing Thank you for your help! |
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. |
The callback is a private static final, so it shouldn't be GCed. The exception is also not "OutOfMemoryError". |
Is the project available somewhere, so that we could get to have a deeper look (ideally buildable in my environment)? |
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? |
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 :-) |
@matthiasblaesing I've sent you a mail (mb*******@d*****-h****.eu) with the download link. Please handle it confidentially. |
@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 The attachment fails (result code is 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:
instead of the SEGFAULT. |
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>
.
|
@matthiasblaesing Thank you so much for your support! Increasing the stack size of the thread in the C lib fix my error. |
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. |
Thank you so much @matthiasblaesing for all your support! |
Version of JNA and related jars
JNA 4.5.1
Version and vendor of the java virtual machine
Oracle JDK 1.8.0_171_x64
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
System architecture (CPU type, bitness of the JVM)
Oracle VM
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.
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
The text was updated successfully, but these errors were encountered: