I debug into C++ JNI code on Linux with GDB. I want to see which java class calls the JNI code, but the callstack only shows blank virtual addresses.
Is there any way to get the class file information of the calling java class?
Regards
Related
I have a umdf driver and I would like to call some functions in .jar files to establish a connection between my driver (PCSC Reader) and an eclipse plugin (JCOP).
I called some java functions (from .jar) in a c++ main using JNI but can we write JNI code in a UMDF driver ?
If yes, I would appreciate some guidelines or point of views about how to approach the subject ...
There aren't much info about the subject when you google it so any info is much appreciated !
Thank you.
I don't have any UMDF driver experience, however, after reading the over view I don't see any reason why JNI would not be able to communicate directly with the Reflector. I don't think it will be able to communicate with the device stack or manager. So, if I understand this correctly, you should probably have some driver you load independently of JNI and then use JNI to talk to the driver via the Reflector.
On a more general note, I would recommend keeping your JNI code as simple as possible. My JNI code usually only functions as a Java <=> Native translation layer. All of the complexity and processing is done in a backing library that can be run independently of Java. By doing that, you can debug your native code with gdb or visual studio without having to jump around an already running JVM. You can choose to either ship the stand alone library as a native dependency and add it the the systems library load path or you can simply link it to the JNI library statically. I have had very good results using LTO and static linking in that exact scenario.
I have a newbie question regarding Lua.
If I embed some Lua script inside my C++ application. When I compile my C++ application, will the Lua script part be compiled into machine code or does C++ application runs the Lua script part each time with Lua interpreter?
The web is saying using LuaJIT will improve embedded script performance greatly, then I guess the Lua script inside C++ application is never compiled into machine code.
If I would like to squeeze every bit of performance in this kind of situation, i.e, I would like to write part of my program in Lua to be embedded in a C++ application. What is my best option? Is there something I can used to compile Lua part into C++/C part and will this improve performance?
The entire point of a JIT compiler is to generate machine code at runtime from the source files.
LuaJIT will look for 'hotspots' in your code that run frequently (such as inner loops or frequently used functions), and try to compile them to machine code. It doesn't matter where the code came from; after loading, that is completely irrelevant.
I have a console-based C++ executable that has been successfully compiled for iPhone (arm7, arm7s, and i386 architectures). I would like to simply call this program (with arguments) and print back the output of the execution. Any ideas on how to go about doing this? In C++ this is done via some kind of popen() thing, but I have no idea how to approach this via Objective-C (especially since there doesn't seem to be any documentation on it).
On OS X, you could use NSTask for this. On iOS your application can't run other processes. You'll have to compile and link the C++ code into your iOS app, and call its functions directly (essentially replacing its main()). Do you mind saying what the C++ executable is?
I have just started reading up on the JNI and guy from the C++ side of our project has just pointed me towards 2 files, the Java Interface and the DLL file.
With the DLL in hand do I need to have any other knowledge of what is going on on the C++ side. Do I now just put the DLL in the class path and access it via the Java interface he has given me? He created a header file using the Java interface and this is included in the .cpp file. From that I assume the DLL was generated.
The following is some of the code I have
System.loadLibrary("PredictionService");
JNIPrediction predictor = new JNIPrediction();
predictor.getPredictions("test");
I don't get any errors so does this mean it is loading the DLL successfully and calling the getPredictions() method inside the DLL?
Basically I was needing to know is this how you use JNI typically.
A 'Java Interface File' is not a commonly defined term. You need at least a C header file or some documentation to indicate how the functions in your DLL need to be called. The only information you're likely to get from the DLL itself is the names of the available methods.
While it is possible to embed debug information in the DLL which describes the DLL method signatures, it's not likely that you have such in your DLL, and you need additional tools to be able to make use of it.
I have an MFC application that uses several MFC extension DLL's. I want this app (and several other similar apps) to be able to access some parts of the .net framework. I wrote a C# library to do the .net work I want and was hoping to be able to write an MFC dll to hide all the C++/CLI code from my apps. The apps would stay as pure MFC apps and the only C++/CLI code would be in my new MFX extension DLL. However when I did this the apps crashed when accessing the new MFC C++/CLI dll. If I put the C++/CLI code in the apps it works ok and I can debug my way all the way in to the C#.
Does anyone understand why the dll idea doesn't work?
Thanks
You can't reference managed assemblies from pure native code. You have to either flip the /clr switch on the consumer (either project-wide or in certain files,) or do some interop.
One interop option that will allow your consumer to say pure native is calling into the managed assembly via COM Callable Wrapper.
I believe I have run into a similar problem. My setup was similar - A pure MFC app with a pure MFC DLL which in turn interacted with the C++/CLI DLL. Everything would run fine, but it would crash on exit. The problem was exacerbated while testing the pure MFC DLL using CppUnit.
On debugging, I found out that due to a bug, my C++ code was throwing first-chance exceptions for access violations (objects referenced via a dangling pointer) on exit. Now, the C++ runtime ignores these violations on exit, whereas the CLR does not. The CLR runtime throws an unhandled exception making it appear that the program / unit-test crashed.
Your problem maybe different, but it does sound quite similar to the one I had.
The MFC dll project references the C# library and has one file compiled with /clr that handles the interface into my C# library. I have actually seen this work sometimes at run time but have never been able to debug into the MFC dll or into the C# code. However it doesn't seem to be at all stable and crashes in the majority of cases.