Java bindings - java.lang.UnsatisfiedLinkError - Invalid access to memory location

[Marek Sieluk]

Hello!

I've just tried to run a MasterDemo application using Java bindings and it's working pretty well under Win 10 64bit - even after exporting to jar.

I also tried to execute it (exactly the same package) on Windows XP (some stubborn clients still refuse to migrate to something modern), and this time it was not so succesfull. Execution failed with error message:

Exception in thread "main" java.lang.UnsatisfiedLinkError: d:\projects\opendnp3_parent_jar\opendnp3java.dll: Invalid access to memory location
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at com.automatak.dnp3.impl.DNP3ManagerFactory.<clinit>(DNP3ManagerFactory.java:46)
at com.automatak.dnp3.example.MasterDemo.main(MasterDemo.java:44)

So, it looks like a problem with loading native library... but I'm wondering if it's even possible to run open-dnp3 on WinXp? OpenSSL is installed on both systems and dependencywalker did not revealed any problems.

Very similar error message was displayed when I tried to run open-dnp3 using .Net bindings (after down-target to .Net 4.0 and set v140_xp as target platform). Also in this scenario MasterDemo application worked well on Win 10 but failed to start on Win XP giving System.BadImageFormatException: Invalid access to memory location. (Exception from HRESULT: 0x800703E6).

So, finally, the question is: is there any chance to run open-dnp3 (using any bindings) on Windows xp?

Best regards,
Marek

[Adam Crain]

Hi Marek,

I've never tried.

Opendnp3 is just a C++ library, so I don't see why it couldn't be compiled to work on Windows XP.

The Visual Studio 2015 C++ runtime is installed on the target?

-Adam

[Adam Crain]

Another possibility is that you have a 32bit/64bit mismatch:

http://stackoverflow.com/questions/13836576/jni-call-c-dll-occured-unsatisfiedlinkerror-invalid-access-to-memory-location

Is the Windows XP JVM also a 64-bit JVM?

[Paul Kennedy]

I don't think java 8 is supported on Windows XP

[Marek Sieluk]

Hi!

1. The Visual Studio 2015 C++ runtime is installed

2. Java used to compile/generate Jar with demo application was 32bit version - both on Win 10 (JDK) and Win XP (just JRE).

3. It's true that Java 8 is not officially supported on Windows XP - but as stated at https://www.java.com/en/download/faq/winxp.xml it still should work - and is working fine with my other projects.

I'm wondering if there is any plain C++ version of demo application? It could be helpful to diagnose the problem location - is it realy someware between bridge/C++ or just in C++.

I'm affraid it could be something with C++ part because I'm getting the same error when using .Net bridge... but no idea how to track it. 

-Marek

[J Adam Crain]

Hi Marek,

Yes, there are C++ example applications:

https://github.com/automatak/dnp3/tree/2.0.x/cpp/examples

-Adam

[J Adam Crain]

Another thing you can try is compiling without TLS support. This would rule out an openssl specific issue on XP.

-Adam

[Marek Sieluk]

Thanks for pointing at C++ example apps - I missed those somehow. 

I tried it and master-demo.exe (pure C++) works properly on XP, so it proofs that bindings should work too... but still no luck there.

I also tried to compile libraries without TLS, as you suggested, but yet again the result was the same: UnsatisfiedLinkError + Invalid access to memory location.

I'm wondering what is the cause of "Invalid access to memory location"... I tought it might be the "VS 2015 C++ Redistributable"-related problem, but those pure c++ demo app also uses it.

I think it's weird that the problem occurs on two independent platforms - .Net and Java. So, if the library itself is good, and the platform-related part is also good then what else? 

I'll be grateful for any hints how to track and solve the problem because I'm running out of ideas...

Thanks,

Marek

[J Adam Crain]

Hi Marek,

I agree that the extra "Invalid access to memory location" is atypical. I've never seen it before. Some cursory googling didn't help either.

I don't have any more suggestions at the moment, but if I think of something else to try I'll reply.

-Adam

[Marek Sieluk]

Hi Adam,

thank you for your assistance. I have one more idea to try... As far as I know cmake is able to generate also MinGW makefiles, so I plan to try to compile the library and the c++ part of the jni bindings using MinGW32. I have a hunch it might be some compiler-related issue (or vs2015 c++ redistributables)... The compiler from VS2015 is the only thing (not counting sources :) ) that connects both .Net and Java bindings (and the "Invalid access..." issue is on both platforms).

I'll share the results...

Best regards,

Marek

[Marek Sieluk]

Hello,

I struggled with MinGW trying to build Java Bindings. 

For now I was able to compile library and dependencies, but not without troubles... 

I had to slightly change "dnp3\java\cpp\adapters\LocalRef.h" to fix "extra qualification" error. The thing I changed is "LocalRef& LocalRef::operator=(LocalRef&) = delete;" which became "LocalRef& operator=(LocalRef&) = delete;".

After that compilation was succesfull. Unfortunately the linking process was not. First I faced the massive amount of "undefined reference to `_imp__WSACleanup@0" and "undefined reference to `_imp__WSAStartup@8'". I think I fixed it by adding "target_link_libraries (asiopal LINK_PUBLIC ${NET_LIBS})" to CMakeLists.txt in DNP3_JAVA section. This brought me to another problem because now I'm having "libasiopal.a(Executor.cpp.obj):Executor.cpp:(.text+0x279): undefined reference to `asiopal::TimeConversions::Convert(std::chrono::time_point<asiopal::SteadyClockWindows, std::chrono::duration<long long, std::ratio<1ll, 1000000000ll> > > const&)'". And I'm not able to fix it yet. It would be great to have some assistance.

Best regards,

Marek

[J Adam Crain]

Hi Marek,

I've pushed a fix for the "extra qualification" bug as this was a general GCC issue.

If I  have time this week, I'll grab MinGW and try this myself.

-Adam

[J Adam Crain]

Marek,

I played around with mingw a bit this evening. Let's work off of this branch:

https://github.com/automatak/dnp3/tree/mingw

I linked in the windows socket libraries, but am still not able to get past those link errors.

If you have a fix can you submit a pull request relative to this branch?

-Adam

[J Adam Crain]

Ok, I got everything compiling and linking in that branch.

The integration tests segfault. The demos crash on program exit.

Not sure the best way to find out what's going on...

-Adam

[Marek Sieluk]

Thank you for the effort spent on that issue. I'll play with the branched version and try to fix the problem... I'll get back with results if succeeded.

-Marek