I've used cygwin to build a dll (which depends on some openssl libraries). Now I'm trying to load the dll using System.loadLibrary. But at that point the application just exits with return code -1073740940.
There is no exception or information. The libraries path is set using -Djava.library.path=path/to/library.
Why is my application crashing without any errors? If there's an error in native code I'd get a message about that, right? And the only static variable I have for sure does not cause a crash.
EDIT
As it turns out, I can generalize this question: Are there any pitfalls when using cygwin to build a dll for the use in java?
Another thing I noticed is that loading the library sometimes causes an immediate exit and sometimes does not finish at all (it just keeps loading the library until I kill the application
Related
I'm working on some code that is acting strange. The code is using the Java reflection property, loading the method name from a JSON file. Works perfectly in Linux, yet, importing and running the same code in the same IDE, with the code running in the same version and profile of a Websphere Application server setup, they are both using the same source files through a file server mount. Other parts of the application manipulate these files without a problem in both environments. Yet, somehow in Windows, it is unable to load the method from the file while Linux can. Stepping through the debugger in Windows I find that the null pointer error occurs at the time of trying to dynamically load the method, while stepping through the code in Linux in the same manner it simply proceeds where Windows gets stuck without issues. I'm getting this null pointer error from the application pointing to a method that does not exist due to the failure to load:
java.lang.NullPointerException
at com.mpi.factory.ToolStateFactory.getToolStateExtended(ToolStateFactory.java:19)
at com.mpi.factory.ToolStateFactory.getToolStateExtended(ToolStateFactory.java:33)
at com.mpi.factory.ToolStateFactory.getToolStateExtended(ToolStateFactory.java:41)
Given that the JRE is supposed to be portable and it shouldn't matter in what environment it runs, I suspect it's related to the OS. Has anyone experienced this issue before? I'm wondering if it's something that needs to be addressed at the OS level, or Java security settings? I know Windows is a bit more glitchy when it comes to drive mounts than Linux. I'm wondering if it's an obvious, well known issue with J2EE projects trying to use reflection in Java. I really don't think this has to do with the Webpshere, or project settings (Classpath, Deployment Descriptor, etc) since they are identical in both environments. Can't really find anything online about this quirk.
I'm facing a strange exception in my Java Web Start application.
It verifies at application start during the loading, then the application crashes with this exception: IllegalStateException: zip file closed.
It doesn't happen in all computer Clients, but I think it doesn't depend on the Java version because I've tried lots of different versions in different O.S..
Also, it doesn't happen at every program execution, only occasionally.
Do you have any ideas of what can cause this?
I used Java Mission Control tool and investigated.
I found some NoSuchMethodError when the application starts. Maybe those Errors could be the problem ?
I am working on a Java application, using JNI interface to a DLL, written in C.
When I launch the application in Eclipse and I try to do an "Attach to process" in the C code (in Visiual Studio 2013), this seems not to be working: my Visual Studio breakpoints mention:
The breakpoint will not currently be hit. No symbols have been loaded for this document.
I have verified the compilation/runtime directories, everything seems to be OK.
One thing I'm not sure about, is the code type I need to use:
As mentioned, my application is a Java application, hence in Visual Studio the project properties, Command parameter, equals
"$(JAVA_HOME)\bin\java.exe"
The name of my Java application is mentioned in the command arguments.
I'm not sure, but I believe my problem is due to a mismatch of the Java.exe program and the code type I need to use. There are six of them (in the window "Debug, Attach to Process, Select (Select Code Type)):
GPU - Software Emulator
Managed (v3.5, v3.0, v2.0)
Managed (v4.5, v4.0)
Native
Script
Managed Compatibility Mode
For elimination purposes, does anybody know how I can determine which of the mentioned code types correspond(s) to the Java program/application? (My first attempts, having Visual Studio determine the code type automatically, have failed)
GPU - Software Emulator
Script
I'm not sure exactly what these mean in the context of Visual Studio, but they're definitely not what you're looking for.
Managed (v3.5, v3.0, v2.0)
Managed (v4.5, v4.0)
Managed Compatibility Mode
"Managed" is Microsoft's fancy way of saying .NET, which you're not using.
Native
Native code is machine code that's been compiled in the traditional way. This is what you want.
I have the situation when two jar libraries use the same shared library.
In each library "the main interface" class loads the .so file with System.loadLibrary.
My question is: if the user decides to use these two jar libraries in one project, would the second call to System.loadLibrary for the same .so file cause any exception? Or is it "somehowe handled" by the system to prevent shared libraries from being loaded twice? Or maybe there is a "commonly known pattern" to handle such situations?
The jni wrappers are targeted to be used on android. I am the author of both wrapper libs so answering you can assume full control on java sources.
According to the apidocs it should not be a problem: "If this method is called more than once with the same library name, the second and subsequent calls are ignored."
I've found one very narrow use case when this will be a problem.
If you are running Android system app, with android:sharedUserId="android.uid.system" in manifest, either pre-installed to the device, or signed with the platform certificate, and you are trying to call System.loadLibrary twice to load the same library (either by running the same app twice, or creating two separate system apps loading the same library), Android will reboot.
Invoking JNI method from this library, if it was not yet loaded, will not generate an exception when running inside android.uid.system process, as with normal Android app - it will reboot Android.
To prevent that, and find out if the library was already loaded, you can read file /proc/self/maps and search for your library name there. ClassLoader and reflection will not help here - they will show JNI methods as accessible even when the library is not yet loaded.
Note that you cannot do if (Runtime.getRuntime().exec("/system/bin/grep <library-name> /proc/self/maps").waitFor() == 0) - system process is forbidden from launching any external commands by SELinux, you will have to read the file from the Java code.
Another quirk is that the library must be preinstalled to device to the /system/lib directory - if you bundle the library with your app, and install the app to device, library will end up in /data/app/..../lib, and when you will try lo load it from /data partition, well you already guessed - Android will reboot.
I have made a java program that creates PDF files based to GnuPdf. It runs perfectly when run using native java code (on windows or iSeries QSH), however, when run through an RPGLE interface, the program crashes (at what seems like random intervals) when processing images. I tracked down one of these down to loading an image from a .jar file and removed the call from the code. It worked for a while but is now crashing for images loaded from IFS. Maybe RPGLE is locking the files somehow, and ideas? The code is called from a Service Program.
Here is the stacktrace
java.lang.NullPointerException
at gnu.jpdf.PDFImage.write(PDFImage.java:286)
at gnu.jpdf.PDFOutput.write(PDFOutput.java:114)
at gnu.jpdf.PDFDocument.write(PDFDocument.java:307)
at gnu.jpdf.PDFJob.end(PDFJob.java:182)
at com.mysite.pdf.PdfDocumentStateValid.endDocument(PdfDocumentStateValid.java:657)
at com.mysite.pdf.PdfDocument.endDocument(PdfDocument.java:36)
java.io.IOException: Descriptor not valid.
at java.lang.Throwable.<init>(Throwable.java:196)
at java.lang.Exception.<init>(Exception.java:41)
at java.io.IOException.<init>(IOException.java:40)
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:260)
at java.io.ByteArrayOutputStream.writeTo(ByteArrayOutputStream.java:112)
at gnu.jpdf.PDFOutput.<init>(PDFOutput.java:96)
at gnu.jpdf.PDFDocument.write(PDFDocument.java:302)
at gnu.jpdf.PDFJob.end(PDFJob.java:182)
at java.awt.PrintJob.finalize(PrintJob.java:60)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:116)
at java.lang.ref.Finalizer.access$100(Finalizer.java:47)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:193)
Changing my answer here now that I can see the stack trace. The problem happens when you hit native code (native meaning you are basically drilling into OS level or OS custom code).
You are getting an IOException of Descriptor not valid (and by that I'm assuming it means the file descriptor (ie, FileDescriptor). Now the big difference between running it in QShell and running it from RPG is that the Java code invoked from RPG is probably invoked under a different ID and/or privilege level. You may have to make modifications to the iSeries to your program to grant it authority for Java to have the right authorities to do what it needs. (I know you would think that is something the SecurityManager in Java would have picked up...but I know wierd things can happens sometimes when you are using a custom JVM (read IBM's) on a custom OS (i5/OS). You are left to the mercy of the vendor (in this case IBM). Give that a shot (the permissions thing) and see if that solves your problem.
Also...I googled and just found this related to iSeries: https://www-304.ibm.com/support/docview.wss?uid=nas379538999e744aad1862575b0006e28ab
So it might be that the jt400 library used by the OS may have a flaw and you may need to PTF it and/or your JVM too. Just another thought of something to try.