invalid mode for dlopen(): Invalid argument

[GoogleCodeExporter]

Bridj fails to load a shared library (which is defintely found in the path) and 
gives the error: invalid mode for dlopen(): Invalid argument 

For a detailed description please refer to this post: 
http://groups.google.com/group/nativelibs4java/browse_thread/thread/1029404cc18a
a72e#

Sample code included. Just extract. Go to directory "c" and type "make". This 
will first clean up, then compile the code (which is a minimalistic example 
according to the example described on http://code.google.com/p/bridj/), and 
afterwards generates a shared library which is then copied to the directory 
"native". Then go to the main directory and type "./testBridj", this will 
execute the corresponding java code from the directory "java" (which is btw an 
eclipse workspace). 

Original issue reported on code.google.com by thomasfr...@gmail.com on 22 Mar 2011 at 5:35

Attachments:

• bridjtest.zip

[GoogleCodeExporter]

Even quicker testing with: cd c && make && cd .. && ./testBridj ;)

Original comment by thomasfr...@gmail.com on 22 Mar 2011 at 5:44

[GoogleCodeExporter]

Hi Thomas,

Sorry for the delay, I hope to be able to diagnose / fix this by the end of 
this week, please bear with me...

Cheers
--
zOlive

Original comment by olivier.chafik@gmail.com on 28 Mar 2011 at 3:02

• Changed state: Accepted

[GoogleCodeExporter]

Dear Olivier,

I have solved the issue. It is all about the C++ name mangeling. Since my C++ 
code is OO marking methods with >>extern "C"<< does not avoid the mangeling. 
Therefore, the method is no longer namend just "normalMethod" but 
"_ZN7MyClass12normalMethodEi" after generating the shared library. You can see 
this by using "nm native/libtest.so" (using "nm -Ca native/libtest.so" like I 
did shows the demangeled name). 

Since there seems to be no way to avoid the mangeling in C++ class member 
functions in Linux (extern "C" does only work for static functions), the only 
chance is to do a manual mapping. Using JNA (which has a mapper functionality) 
I was able to execute my code without errors. However, it seems that BridJ does 
not have this functionaly at the moment, so no chance for me to use BridJ with 
my OO C++ code at the moment.

Original comment by thomasfr...@gmail.com on 31 Mar 2011 at 8:57

[GoogleCodeExporter]

Hi again,

I just wanted to say "thank you" anyways. Allthough BridJ seems not be suitable 
for my coding problem / platform your help was really appreciated!

Thanks and if you are interested in the working JNA code, please just reply, I 
will upload the working code!

Original comment by thomasfr...@gmail.com on 31 Mar 2011 at 9:17

[GoogleCodeExporter]

Hi Thomas,

BridJ handles C++ demangling automatically in all non-pathological cases (along 
with C stdcall demangling).
It also has a manual @Symbol annotation that takes the exact mangled symbol.
The issue here is more related to the behaviour of dlopen and the options it 
accepts. BridJ and JNA use different options and I hope to be able to fix and 
test this by the end of the week.
As for the working code, it would be nice if you could upload it so that I can 
port it to BridJ and prove you it can work after a small fix :-)

Cheers
--
zOlive

Original comment by olivier.chafik@gmail.com on 31 Mar 2011 at 2:43

[GoogleCodeExporter]

Dear Olivier,

I tried using the @Symbol annotation with the same value I used in JNA function 
mapper, still the same error in BridJ - so you are probably right that the 
problem is related to some other issue.

Please find the code attacted which additonally includes the working JNA code. 
There are some new Java classes which use the same c-code as before. In case 
you recompile the C-Code you may have to change the name mapping for JNA (see 
class de.jnatest.MyFunctionMapper.java). To test the JNA implementations, just 
execute "./testJNA".

Looking forward to your fix!

Original comment by thomasfr...@gmail.com on 31 Mar 2011 at 3:30

Attachments:

• bridjtest.zip

[GoogleCodeExporter]

Hi Thomas,

I've just deployed a new snapshot of BridJ which behaves much better :-)
(it appears to fix the issue with your provided sample)

http://nativelibs4java.sourceforge.net/maven/com/nativelibs4java/bridj/0.4-SNAPS
HOT/bridj-0.4-SNAPSHOT-shaded.jar

Please let me know if you face any further issue :-)
Thanks for your patience !

Cheers
--
zOlive

Original comment by olivier.chafik@gmail.com on 1 Apr 2011 at 2:40

• Changed state: Fixed

[GoogleCodeExporter]

Dear Olivier,

thanks for your work!

However, I have to say that the issue is not fully solved (at least on my 
machine). With the new snapshot, the method is found and even executed but the 
script ends with a JVM crash:
$ ./testBridj
Hello world!
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xb4914000, pid=2135, tid=3028286320
#
# JRE version: 6.0_20-b02
# Java VM: Java HotSpot(TM) Client VM (16.3-b01 mixed mode, sharing linux-x86 )
# Problematic frame:
# C  0xb4914000
#
# An error report file with more information is saved as:
# /home/itug/bridjtest/hs_err_pid2135.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
./testBridj: line 4:  2135 Aborted                 java -cp 
./java/bridjtest/bin:./java/bridjtest/lib/* de.bridjtest.TestLibraryTester

I have attached the sources (including the crash dump) so that you can 
crosscheck. Any ideas on this?

Anyways, thanks again!

Original comment by thomasfr...@gmail.com on 4 Apr 2011 at 8:09

Attachments:

• bridjtest.zip

[GoogleCodeExporter]

Original comment by olivier.chafik@gmail.com on 4 Apr 2011 at 4:21

• Changed state: Started

[GoogleCodeExporter]

Hi Thomas,

Something weird is happening here : I suspect the library is somehow unloaded 
too early (before your C++ class is GC'd), or something in that style. I need 
to investigate this issue more, but in the meanwhile you can avoid issues by 
manually releasing your class as follows :

import org.bridj.BridJ;
...

MyClass test = new MyClass();
try {
    test.normalMethod(1);
} finally {
    BridJ.delete(test); // equivalent to C++ `delete test;`
}

Cheers
--
zOlive

Original comment by olivier.chafik@gmail.com on 4 Apr 2011 at 5:05

[GoogleCodeExporter]

Hi Thomas,

The crash was caused by a dangerous shutdown hook that unregistered all the 
BridJ-allocated callbacks, even when pending C++ objects were yet to be 
garbage-collected (which requires having access to the C++ destructors' 
callbacks).
I've removed the hook in revision #1850 and have redeployed the 0.4-SNAPSHOT 
Maven version :-)

Thanks again for your help,
Cheers
--
zOlive

Original comment by olivier.chafik@gmail.com on 5 Apr 2011 at 1:59

• Changed state: Fixed