SetOut() through JNI ignored

I'm trying to redirect System.out/err through JNI within
a JNI application which allows running a java class as
a service. Essentially I have the following two classes:
class Service {
void init() { ...
void start() { ...
class LogUtil {
void setOut(String path) {
System.setOut(new PrintStream
(new FileOutputStream(path)));
Now from JNI, i invoke first LogUtil.setOut() to redirect
the stdout, then run the Service class itself. However,
even though the redirection seems to work fine, the
actual java stdout stream is not redirected. It is still
being written to the console. However, if I call the
method LogUtil.setOut() from within Service.init() (which
is also being invoked through JNI), then all works ok.
Any ideas how this could happen?
Help greatly appreciated,
roman

I have the same problem, I get Java level output redirected ok but the printf's from the native side are not.
What did you do differently?

Similar Messages

  • Trying to Load a BufferedImage from a PNG through JNI

    Yes I realize that I can load it directly through Java and not go through JNI, but I need this to test correctly as my C code will aquire images without saving to Disk and I want Java code to manipulate the images without saving to disk. The image Im trying to load is a 800x600 PNG image.
    So I have the code
    import java.io.ByteArrayInputStream;
    import java.io.File;
    import java.io.IOException;
    import java.io.InputStream;
    import javax.imageio.ImageIO;
    import javax.swing.*;
    import com.sun.media.jai.widget.DisplayJAI;
    class ImageLoader{
         static{
              System.loadLibrary("LoadImage");
         private static native byte[] loadImage();
         public static void main(String[] args){
    byte[] f = loadImage();
              InputStream s= new ByteArrayInputStream(f);
              BufferedImage bi;
              try {
                   bi = ImageIO.read(s);
                   displayBufferedImage(bi, "test");
              } catch (IOException e) {
                   // TODO Auto-generated catch block
                   e.printStackTrace();
          * Utility method for display a BufferedImage.<br>
          * @param  image input image
          * @param  title window title string
         public static void displayBufferedImage(BufferedImage image, String title)
              JFrame frame = new JFrame();
             frame.setTitle(title);
             //frame.getContentPane().add(new DisplayTwoSynchronizedImages(sourceImgBI, resultImgGray));
             frame.getContentPane().add(new JScrollPane(new DisplayJAI(image)));
             //frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
             //frame.pack();
             frame.setSize(300,300);
             frame.setLocationRelativeTo( null );
             frame.setVisible(true); // show the frame.
         }and I have the JNI c code as
    char* result;
    JNIEXPORT jbyteArray JNICALL Java_ImageLoader_loadImage
      (JNIEnv * env, jclass jclassj){
                   int fd = open("test.png",  O_RDWR, S_IRUSR|S_IWUSR );
                   int size = (800*600*4);
                   result = (char*)malloc(size);
                   read(fd, result, size);
                   jbyteArray return_result;
                   return_result = env->NewByteArray(800*600);
                   env->SetByteArrayRegion(return_result, 0, 800*600, (jbyte*)result);
                   //free(result);
                   return return_result;
         }but when I try to run the code I get the following error
    javax.imageio.IIOException: Error reading PNG image data
         at com.sun.imageio.plugins.png.PNGImageReader.readImage(PNGImageReader.java:1287)
         at com.sun.imageio.plugins.png.PNGImageReader.read(PNGImageReader.java:1552)
         at javax.imageio.ImageIO.read(ImageIO.java:1438)
         at javax.imageio.ImageIO.read(ImageIO.java:1342)
         at ImageLoader.main(ImageLoader.java:31)
    Caused by: java.io.EOFException: Unexpected end of ZLIB input stream
         at java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:240)
         at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158)
         at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
         at java.io.BufferedInputStream.read1(BufferedInputStream.java:275)
         at java.io.BufferedInputStream.read(BufferedInputStream.java:334)
         at java.io.DataInputStream.readFully(DataInputStream.java:195)
         at com.sun.imageio.plugins.png.PNGImageReader.decodePass(PNGImageReader.java:1084)
         at com.sun.imageio.plugins.png.PNGImageReader.decodeImage(PNGImageReader.java:1188)
         at com.sun.imageio.plugins.png.PNGImageReader.readImage(PNGImageReader.java:1280)
         ... 4 moreI think that Im on the right track because Java is recognizing that this is a PNG image, but Im not sure whats wrong. I don't know much about the formats, so I know nothing about PNG's, maybe someone else can help me here.
    Note: I ran the code
                   BufferedImage bi2 = ImageIO.read(new File("test.png"));
                   displayBufferedImage(bi2, "test2");and the image loads fine, so there is no issue with the image itself.

                   int fd = open("test.png", O_RDWR, S_IRUSR|S_IWUSR );Why are you opening the image file read/write? Why not read-only?
                   int size = (800*600*4);Here you're assuming the image is 800*600. Are you sure that's the case? Also you should write sizeof int here instead of 4.
                   result = (char*)malloc(size);Here you aren't checking for the possibility that result is null.
                   read(fd, result, size);Here you are ignoring the result returned by read(), so you are ignoring the possibilty that it was 0 or less than 'size'. Either are possible.
                   jbyteArray return_result;
                   return_result = env->NewByteArray(800*600);Here again you aren't testing for return_result == null.
                   env->SetByteArrayRegion(return_result, 0, 800*600, (jbyte*)result);Here you should be checking for Java exceptions. Also you shouldn't be repeating the 800*600 here, make it a constant or a variable somewhere.
                   //free(result);You need that free, otherwise you have a memory leak. If the image really is a constant 800*600 in size I would allocate 'result' on the stack so you don't need to housekeep it.
    Also you are never closing the input file!
    Caused by: java.io.EOFException: Unexpected end of ZLIB input streamSo clearly you didn't read all the image. That could be due to guessing wrong about 800*600 or getting a short read when reading the file.
    I think that Im on the right track because Java is recognizing that this is a PNG imageI agree. It starts like a PNG image, so you read something, but it doesn't end like one, so you didn't read it all.> and the image loads fine, so there is no issue with the image itself.
    Good test. Note that your Java code makes no assumption about the size of the image.

  • Korean characters, not handled through JNI

    Hello:
    I have a C library that is wrapped through JNI. The data is in Korean, and is returning fine in the C code, but then when I access the data through Java (JString), it is all messed up. Any ideas what is the problem?
    Thanks,
    [email protected]

    Adding on, here is the snippet code, where a command is passed in. The C code executes the command, and returns the result. The UTF and jstring string manipulations are shown below. What is wrong with the assumption if the data itself is of Korean language (double-byte enabled)? Any response would be greatly appreciated. Please respond to this message board, or email at [email protected]
    Thanks,
    Bilal
    JNIEXPORT jshort JNICALL
    Java_execCliCommand(
    JNIEnv *env, jobject obj, jstring cliCmd, jobject cliOutObj)
    jshort jresult;
    P_HANDLE cliOut = (P_HANDLE)NULL;
    char cliOutBuf = (char )NULL;
    jclass jcliOutClass;
    jfieldID joutbufID;
    jstring jcliOutStr;
    * Get the cli command & connectstring and execute the cli.
    const char cliCmdStr = (env)->GetStringUTFChars(env, cliCmd, 0);
    printf("CLI COMMAND : %s\n", (char *)cliCmdStr);
    jresult = cliRunServerCommand((char *)cliCmdStr, &cliOut);
    jcliOutClass = (*env)->GetObjectClass(env, cliOutObj);
    joutbufID = (*env)->GetFieldID(env, jcliOutClass, "outbuf", "Ljava/lang/String;");
    if ( cliOutBuf != NULL ) {
    printf("CLI RESULTS: %s\n", cliOutBuf);
    jcliOutStr = (*env)->NewString(env, (jchar *)cliOutBuf, (jsize)(p_strlen(cliOutBuf)+1));
    printf("UNICODE CLI RESULTS: %s\n", (char *)(*env)->GetStringChars(env, jcliOutStr,0));
    } else {
    jcliOutStr = (*env)->NewStringUTF(env, "Command executed successfully");
    (*env)->SetObjectField(env, cliOutObj, joutbufID, jcliOutStr);
    (*env)->ReleaseStringUTFChars(env, cliCmd, cliCmdStr);
    (*env)->ReleaseStringUTFChars(env, connectString, connectStr);
    return jresult;
    }

  • Is JMF use hardware accelerated through JNI possible?

    Dear all:
    I try to use JMF decode MPEG-2 data, through VeXP which wrote in C.
    So I think we can call C library through JNI pass encoded MPEG-2 data to VeXP, use hardware decode encoded MPEG-2 data to YUV-format raw data then return it to JAVA.
    but JNI seem can't pass media raw data by call by reference...
    It should cause a lot of memory copy.
    How about it's feasibility?
    Have anyone give me some suggestion?
    Regards,
    white

    There's a few ways to do it, but I'd use a style sheet. So:
    1. Add this to the "creationComplete" Stage event:   sym.$("<link rel='stylesheet' type='text/css' href='styles.css'>").appendTo("#Stage");
    2. Create a style sheet (text file) in your project folder named "styles.css", and define a class:
    .force-webkit-acceleration {
         -webkit-transform: translate3d(0,0,0);
    3. Give your animated element the class "force-webkit-acceleration" in the properties panel (the little c-in-a-box icon next to the title field).
    Be sure that the style sheet file ends up in your "publish/web" folder too.

  • Getting HeapDump on out of memory error when executing method through JNI

    I have a C++ code that executes a method inside the jvm through the JNI.
    I have a memory leak in my java code that results an out of memory error, this exception is caught in my C++ code and as a result the heap dump is not created on the disk.
    I am running the jvm with
    -XX:+HeapDumpOnOutOfMemoryError
    -XX:HeapDumpPath=C:\x.hprof
    Any suggestions?
    Thanks

    I'll rephrase it then.
    I have a java class named PbsExecuter and one static method in it ExecuteCommand.
    I am calling this method through JNI (using CallStaticObjectMethod). sometimes this method causes the jvm to throw OutOfMemoryError and I would like to get a heap dump on the disk when this happens in order to locate my memory leak.
    I've started the jvm with JNI_CreateJavaVM and I've put two options inside the JavaVMInitArgs that is used to create the Jvm. -XX:+HeapDumpOnOutOfMemoryError and -XX:HeapDumpPath=C:\x.hprof
    which supposed to create a heap dump on the disk when OutOfMemoryError occurs.
    Normally if I would execute normal java code, when this exception would occur and I wouldn't catch it the Jvm would crash and the heap dump would be created on the disk.
    Since I need to handle errors in my C++ code I am use ExceptionOccured() and extracts the exception message from the exception it self and write it.
    For some reason when I execute this method through JNI it doesn't create the dump.

  • Passing Image data through JNI?

    Hello,
    I am trying find the fastest way to pass image data from Java through JNI. Passing Java images through JNI seems to be a very common thing to do so I expect there's an oft-used approach. Can anyone give me a good explanation of this or point me to some references?
    I need to pass the image data to a C++ function which operates on this data, writing the results to a destination buffer which goes back to Java and gets put back into an image.
    Currently, I'm using BufferedImages and getRGB to get an int array from my source image, passing this through JNI along with another int array to be used as the destination buffer, then calling setRGB with my destination buffer after the JNI function returns. getRGB() preserves the alpha channel of png files, which is functionality I need. The problem with this approach is that getRGB is extremely slow. It can take up to two seconds with a large image on my 1.2 Ghz Athlon. It seems to be performing a copy of the entire source image's data. Maybe there is a way to decode a jpg or png directly into an int array?
    -Aaron Dwyer

    Here's how you could do it for TYPE_4BYTE_ABGR
    BufferedImage img=new BufferedImage(13,10,BufferedImage.TYPE_4BYTE_ABGR);
    img.setRGB(0,0,0xff0000);     
    img.setRGB(5,1,0x00ff00);        
    img.setRGB(1,1,0xcafebabe);
    DataBuffer db=img.getRaster().getDataBuffer();
    int dataType=db.getDataType();
    if (dataType!=DataBuffer.TYPE_BYTE)
         throw new IllegalStateException("I can do it only for TYPE_BYTE");
    int imgType=img.getType();
    if (imgType!=BufferedImage.TYPE_4BYTE_ABGR)
         throw new IllegalStateException("I can do it only for TYPE_4BYTE_ABGR");
    DataBufferByte dbi=(DataBufferByte)db;
    byte[] array=dbi.getData();
    SampleModel model=img.getSampleModel();
    if (!(model instanceof PixelInterleavedSampleModel))
         throw new IllegalStateException("I can do it only for PixelInterleavedSampleModel");
    PixelInterleavedSampleModel pisModel=(PixelInterleavedSampleModel)model;
    if (pisModel.getPixelStride()!=4)
         throw new IllegalStateException("I can do it only for pixel stride of 4");
    if (dbi.getNumBanks()!=1)
         throw new IllegalStateException("I can do it only for 1 band");
    int scanlineBytes=pisModel.getScanlineStride();
    // Access the green Pixel on Position 5,1
    System.out.println( (int)array[5*4 + scanlineBytes] &0xff);     // Alpha        
    System.out.println( (int)array[5*4+1 + scanlineBytes] &0xff);     // Red        
    System.out.println( (int)array[5*4+2 + scanlineBytes] &0xff);     // Green        
    System.out.println( (int)array[5*4+3 + scanlineBytes] &0xff);     // Blue     I've added some checks to make sure we're accessing the data the right way.

  • JSP  Call  C  Library  through  JNI  ?

    Hi experts :
    I has a jsp file which create a bean to call native c method.
    It still works fine after 10 to 14 times' page refresh, then
    it throws exception when call a native method.
    If I restart the Tomcat it works again ,but shuch situtation repeat again.
    Should I notice any issues when access native c library
    through JNI in jsp ?
    Environment:
    SPARC 64 Solaris 7
    Tomcat 4.0.4
    JDK 1.3.1-04

    hi CTSteven
    Did you find a solution for this JNI-Problem ? I think i have the same problem as you. Would be great to here from you.
    Thank you.
    Bye
    Lukas

  • Casting through JNI

    Hello everyone,
    I'm having myself a little problem. I hava a program in C++ which uses some Java classes through JNI. When i'm invoking a method on a class in Java i get back an object of some type A. But what i need in my C++ program is an object of type B so what i'm looking for is a mechanism to cast my jobject from type A to type B.
    Someone knows how to do this?
    Thanks in advance,
    Bram

    you might want to paste some source code examples in this case.
    you're java objects with be of the base jobject type in JNI/C++ - so you shouldn't need to cast. What method are you using in JNI to invoke?

  • Debugging Java code from c++ through JNI

    I have c++ application calling java methods through JNI. From c++ when I call the java method through JNI how do I debug the java code? It would be of great help if I get to know the settings that I need to do. I am using VC 6.0 for C++ and JBUIlder 8 for JAVA application.OS used is Windows 2000.

    Put
    _asm { int 3 } to C code in the proper place and start your java application. When C code reaches this debug break it shows a dialog to attach the debugger. Attach C debugger and debug Java and C codes.

  • Java.lang.Class- getFields() results in JVM crash when called through JNI

    From a C++ application, I use Invocation APIs to create a JVM and call some Java methods using JNI
    I get a crash in jvm.dll with EXCEPTION_ACCESS_VIOLATION
    when I try to call "getFields" method of java.lang.Class in order to get the Fields of the java class
    This method call, should return a java/lang/reflect/Fields[] on success
    I am able to get the method ID of this method by using pEnv->GetMethodID(..)
    However, when I call this method using CallObjectMethod(..), HotSpt JVM crashes with access violation with the dump given below.
    Any clues on how to debug and find the problem?
    Or has anyone tried getting the fields of a Java class from C++ by calling reflection APIs uing JNI?
    Thanks in advance!
    Sample code
    jclass testerClass = pEnv->FindClass("com/test/Tester");
    jmethodID cid = pEnv->GetMethodID(testerClass,"<init>","()V");
    if(NULL == cid)
    pEnv->ExceptionDescribe();
    jobject testerObject = pEnv->NewObjectV(testerClass, mid);
    jmethodID mid = pEnv->GetMethodID(testerClass, "getClass",
                             "()Ljava/lang/Class;");
    jobject clsObj = (jobject)pEnv->CallObjectMethod(testerObject, mid);
    pEnv->ExceptionDescribe();
    jclass      jCls = pEnv->GetObjectClass(clsObj);
    jmethodID midGetFields = pEnv->GetMethodID(jCls, "getFields",
                                            "()[Ljava/lang/reflect/Field;");
    jobjectArray jobjArray = (jobjectArray)pEnv->CallObjectMethod(testerObject, midGetFields);
    pEnv->ExceptionDescribe();
    Crash dump
    Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at PC=0x809E69F
    Function=JVM_FindSignal+0x11505
    Library=D:\Java\j2re1.4.2_03\bin\client\jvm.dll
    Current Java thread:
         at java.lang.Class.privateGetDeclaredFields(Unknown Source)
         at java.lang.Class.privateGetPublicFields(Unknown Source)
         at java.lang.Class.getFields(Unknown Source)
    Dynamic libraries:
    0x00400000 - 0x00419000      E:\SC\SC12.1\SCApplications\SNMP\Bin\JNITester.exe
    0x77F50000 - 0x77FF7000      C:\WINDOWS\System32\ntdll.dll
    0x77E60000 - 0x77F46000      C:\WINDOWS\system32\kernel32.dll
    0x10000000 - 0x10023000      E:\SC\SC12.1\SCApplications\SNMP\Bin\JniUtils.dll
    0x00320000 - 0x00332000      E:\SnmpIpmNativeTestDriver\MTFStubHelper.dll
    0x00340000 - 0x0035B000      E:\SnmpIpmNativeTestDriver\MTFXMLFileAPI.dll
    0x12000000 - 0x122B1000      e:\sc\sc12.1\bin\xerces-c_2_2_0D.dll
    0x77DD0000 - 0x77E5D000      C:\WINDOWS\system32\ADVAPI32.dll
    0x78000000 - 0x78086000      C:\WINDOWS\system32\RPCRT4.dll
    0x10200000 - 0x1026C000      e:\sc\sc12.1\bin\MSVCRTD.dll
    0x102A0000 - 0x102B7000      e:\sc\sc12.1\bin\MSVCIRTD.dll
    0x5F800000 - 0x5F8E9000      e:\sc\sc12.1\bin\MFC42uD.DLL
    0x77C70000 - 0x77CB0000      C:\WINDOWS\system32\GDI32.dll
    0x77D40000 - 0x77DCC000      C:\WINDOWS\system32\USER32.dll
    0x5F700000 - 0x5F746000      e:\sc\sc12.1\bin\MFCD42uD.DLL
    0x5F500000 - 0x5F5C6000      e:\sc\sc12.1\bin\MFCO42uD.DLL
    0x10480000 - 0x104FE000      e:\sc\sc12.1\bin\MSVCP60D.dll
    0x15020000 - 0x15042000      e:\sc\sc12.1\bin\SCTraceLib.dll
    0x6D510000 - 0x6D58D000      C:\WINDOWS\System32\dbghelp.dll
    0x77C10000 - 0x77C63000      C:\WINDOWS\system32\msvcrt.dll
    0x77C00000 - 0x77C07000      C:\WINDOWS\system32\VERSION.dll
    0x00360000 - 0x0037D000      e:\sc\sc12.1\bin\SCFileManager.dll
    0x76BF0000 - 0x76BFB000      C:\WINDOWS\System32\PSAPI.DLL
    0x00420000 - 0x00580000      e:\sc\sc12.1\bin\BctCoreCL.dll
    0x5D920000 - 0x5D929000      C:\WINDOWS\System32\RPCNS4.dll
    0x71B20000 - 0x71B31000      C:\WINDOWS\system32\MPR.dll
    0x71C20000 - 0x71C6E000      C:\WINDOWS\System32\NETAPI32.dll
    0x71AB0000 - 0x71AC5000      C:\WINDOWS\System32\WS2_32.dll
    0x71AA0000 - 0x71AA8000      C:\WINDOWS\System32\WS2HELP.dll
    0x15000000 - 0x15012000      e:\sc\sc12.1\bin\CTEventLog.dll
    0x773D0000 - 0x77BC2000      C:\WINDOWS\system32\SHELL32.dll
    0x70A70000 - 0x70AD4000      C:\WINDOWS\system32\SHLWAPI.dll
    0x771B0000 - 0x772D1000      C:\WINDOWS\system32\ole32.dll
    0x77120000 - 0x771AB000      C:\WINDOWS\system32\OLEAUT32.dll
    0x1F7A0000 - 0x1F7D6000      C:\WINDOWS\System32\ODBC32.dll
    0x77340000 - 0x773CB000      C:\WINDOWS\system32\COMCTL32.dll
    0x763B0000 - 0x763F5000      C:\WINDOWS\system32\comdlg32.dll
    0x08000000 - 0x08138000      D:\Java\j2re1.4.2_03\bin\client\jvm.dll
    0x76B40000 - 0x76B6C000      C:\WINDOWS\System32\WINMM.dll
    0x5FD00000 - 0x5FD0D000      C:\WINDOWS\System32\MFC42LOC.DLL
    0x71950000 - 0x71A34000      C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.10.0_x-ww_f7fb5805\comctl32.dll
    0x1F840000 - 0x1F857000      C:\WINDOWS\System32\odbcint.dll
    0x5DAC0000 - 0x5DAC7000      C:\WINDOWS\System32\rdpsnd.dll
    0x00FE0000 - 0x00FE7000      D:\Java\j2re1.4.2_03\bin\hpi.dll
    0x01000000 - 0x0100E000      D:\Java\j2re1.4.2_03\bin\verify.dll
    0x01010000 - 0x01029000      D:\Java\j2re1.4.2_03\bin\java.dll
    0x01030000 - 0x0103D000      D:\Java\j2re1.4.2_03\bin\zip.dll
    0x76C90000 - 0x76CB2000      C:\WINDOWS\system32\imagehlp.dll
    Heap at VM Abort:
    Heap
    def new generation total 576K, used 132K [0x15050000, 0x150f0000, 0x15530000)
    eden space 512K, 25% used [0x15050000, 0x15071250, 0x150d0000)
    from space 64K, 0% used [0x150d0000, 0x150d0000, 0x150e0000)
    to space 64K, 0% used [0x150e0000, 0x150e0000, 0x150f0000)
    tenured generation total 1408K, used 0K [0x15530000, 0x15690000, 0x19050000)
    the space 1408K, 0% used [0x15530000, 0x15530000, 0x15530200, 0x15690000)
    compacting perm gen total 4096K, used 964K [0x19050000, 0x19450000, 0x1d050000)
    the space 4096K, 23% used [0x19050000, 0x191410e0, 0x19141200, 0x19450000)
    Local Time = Wed Aug 25 21:06:44 2004
    Elapsed Time = 0
    # HotSpot Virtual Machine Error : EXCEPTION_ACCESS_VIOLATION
    # Error ID : 4F530E43505002EF
    # Please report this error at
    # http://java.sun.com/cgi-bin/bugreport.cgi
    # Java VM: Java HotSpot(TM) Client VM (1.4.2_03-b02 mixed mode)

    You are right, I tried getting the java.lang.Class reference for the com.test.Tester by calling getClass() on com.test.Tester
    And using this jclass reference for java.lang.Class, I tried getting the method ID of getFields and eventually the Field[]
    Thanks for the help
    I have some more questions.
    Assumption - Using JNI, I got the fields array of com.test.Tester and I am iterating through the fields
    1.Assuming that the Tester class had an Integer field say m_nIntVal, then once I get the jobject equivalent of this Field in C++.
    Now I need to get the type of the field (I call the method java.lang.reflect.getType() from JNI)
    This gives me a jclass reference to it's type i.e java.lang.Integer
    2.I need to get the name of this type i.e I want to get the name of the type in a string as "java.lang.Integer"
    For this, on the jclass reference of java.lang.Integer got in Step 1, I call getClass() from JNI (to get the java.lang.Class) and then getName()
    Now, for calling getClass(), I need a temporary object reference corresponding to the jclass of java.lang.Integer, The problem is that Integer does not have a default constructor, so my call to create the jobject fails.
    But, since I do not know that I am constructing an Integer (remember that is what I am trying to find out - getType), I cant pass any values to constructor
    Now, how do I go about creating a jobject of Integer, without knowing that I am constructing that, as this does not have a default constructor without parameters
    Also, I tried using AllocObject to get the jobject and then tried to get the method ID of getClass(). Even this failed
    3. If the com.test.Tester class had a primitive "int" field, say m_nPrimitiveInt
    for which java provides a Class representation, I am able to get the jclass reference to the type of m_nPrimitiveInt
    Now, how do I get the name of the type as "int" in a string?
    Forllowing a similar procedure like in Step 2 fails when I try to pass the jclass reference to the type of m_nPrimitiveInt to the GetMethodID
    with the error FATAL ERROR in native method: JNI received a class argument that is not a class
    Can you tell me what is the way out?
    Thanks in advance,
    Also, can I mail you with some doubts that I have? If its ok, please contact me at [email protected]

  • Memory Leakage in dlls called through JNI

    I have some dll that are called through a JNI code that have a memory leakage. I need to find how much is that.
    Do we have some functions for that to find it in the code.Is that possible without making changes in the JNI code.
    I checked but all suggest a memory leakage tool.But i want to do that writing a code in Java.I have checked for the Runtime class but it only finds the JVM related memory usage and not the dll one.

    amol28 wrote:
    But i want to do that writing a code in Java.Not possible. JNI/C/C++ is not java. So you can't use java to verify it.
    I checked but all suggest a memory leakage toolEither that or you manually inspect and/or test the code yourself (in C/C++).

  • IMSL C library causes JVM crash through JNI in GC with JDK 1.6

    Hi Java friends,
    We use the IMSL C library (made by Visual Numerics) via JNI which picks up a C++ so on Linux. Under JDK 1.5 it works fine. Under 1.6 it crashes in the GC. I put together a very simple testcase that just calls the IMSL error options function (which sets up the library) and it causes the JVM to crash somewhere in the GC. The reason I know it's in the GC is that the crash is not immediate, it's only when the GC is active, so we wrote some test code to push the GC like this:
    log("Looping");
    long block = 10000000;
    int numBlocks = 10;
    long loops = block * numBlocks;
    for (long i = 0; i < loops; i++) {
    // Create some objects that need disposal
    String.valueOf(i);
    if (i % block == 0) {
    log("Reached " + i);
    System.gc();
    Anyone got any idea why? Crash dump follows.
    Many thanks,
    David.
    # An unexpected error has been detected by Java Runtime Environment:
    # SIGSEGV (0xb) at pc=0x00000000, pid=23854, tid=4143893424
    # Java VM: Java HotSpot(TM) Server VM (1.6.0_03-b05 mixed mode)
    # If you would like to submit a bug report, please visit:
    # http://java.sun.com/webapps/bugreport/crash.jsp
    --------------- T H R E A D ---------------
    Current thread (0x08058c00): JavaThread "main" [_thread_in_Java, id=23855]
    siginfo:
    [error occurred during error reporting, step 90, id 0xb]
    Stack: [0xf6f9c000,0xf6fed000), sp=0xf6feb55c, free space=317k
    Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
    V [libjvm.so+0x53b9a7]
    V [libjvm.so+0x53c5b4]
    C [libpthread.so.0+0xb890]
    V [libjvm.so+0x53b3f5]
    V [libjvm.so+0x53b9a7]
    V [libjvm.so+0x4541d0]
    V [libjvm.so+0x451a68]
    --------------- P R O C E S S ---------------
    Java Threads: ( => current thread )
    0x08157c00 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=23866]
    0x08155c00 JavaThread "CompilerThread1" daemon [_thread_blocked, id=23865]
    0x08154800 JavaThread "CompilerThread0" daemon [_thread_blocked, id=23864]
    0x08153400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=23863]
    0x08140400 JavaThread "Finalizer" daemon [_thread_blocked, id=23862]
    0x0813f800 JavaThread "Reference Handler" daemon [_thread_blocked, id=23861]
    =>0x08058c00 JavaThread "main" [_thread_in_Java, id=23855]
    Other Threads:
    0x0813d000 VMThread [id=23860]
    0x08159400 WatcherThread [id=23867]
    VM state:synchronizing (normal execution)
    VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event])
    [0x08056d60/0x08056d88] Safepoint_lock - owner thread: 0x0813d000
    [0x08056de0/0x08056e08] Threads_lock - owner thread: 0x0813d000
    Heap
    PSYoungGen total 87040K, used 8962K [0xecca0000, 0xf21e0000, 0xf3e60000)
    eden space 86784K, 10% used [0xecca0000,0xed528b98,0xf2160000)
    from space 256K, 87% used [0xf21a0000,0xf21d8040,0xf21e0000)
    to space 256K, 0% used [0xf2160000,0xf2160000,0xf21a0000)
    PSOldGen total 230976K, used 0K [0xb3e60000, 0xc1ff0000, 0xecca0000)
    object space 230976K, 0% used [0xb3e60000,0xb3e60000,0xc1ff0000)
    PSPermGen total 16384K, used 2540K [0xafe60000, 0xb0e60000, 0xb3e60000)
    object space 16384K, 15% used [0xafe60000,0xb00db1d8,0xb0e60000)
    Dynamic libraries:
    0085a000-0086f000 r-xp 00000000 68:06 213117 /lib/ld-2.3.4.so
    0086f000-00870000 r-xp 00015000 68:06 213117 /lib/ld-2.3.4.so
    00870000-00871000 rwxp 00016000 68:06 213117 /lib/ld-2.3.4.so
    00873000-00875000 r-xp 00000000 68:06 213179 /lib/libdl-2.3.4.so
    00875000-00877000 rwxp 00001000 68:06 213179 /lib/libdl-2.3.4.so
    0089b000-009c0000 r-xp 00000000 68:06 213118 /lib/tls/libc-2.3.4.so
    009c0000-009c1000 r-xp 00124000 68:06 213118 /lib/tls/libc-2.3.4.so
    009c1000-009c4000 rwxp 00125000 68:06 213118 /lib/tls/libc-2.3.4.so
    009c4000-009c6000 rwxp 009c4000 00:00 0
    009c8000-009e9000 r-xp 00000000 68:06 213200 /lib/tls/libm-2.3.4.so
    009e9000-009eb000 rwxp 00020000 68:06 213200 /lib/tls/libm-2.3.4.so
    009ed000-009fb000 r-xp 00000000 68:06 213087 /lib/tls/libpthread-2.3.4.so
    009fb000-009fd000 rwxp 0000d000 68:06 213087 /lib/tls/libpthread-2.3.4.so
    009fd000-009ff000 rwxp 009fd000 00:00 0
    00a01000-00a09000 r-xp 00000000 68:06 213205 /lib/tls/librt-2.3.4.so
    00a09000-00a0b000 rwxp 00007000 68:06 213205 /lib/tls/librt-2.3.4.so
    00a0b000-00a15000 rwxp 00a0b000 00:00 0
    00a31000-00a43000 r-xp 00000000 68:06 213202 /lib/libnsl-2.3.4.so
    00a43000-00a45000 rwxp 00011000 68:06 213202 /lib/libnsl-2.3.4.so
    00a45000-00a47000 rwxp 00a45000 00:00 0
    06000000-065a0000 r-xp 00000000 00:1c 172281 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/server/libjvm.so
    065a0000-065db000 rwxp 005a0000 00:1c 172281 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/server/libjvm.so
    065db000-069fc000 rwxp 065db000 00:00 0
    08048000-08052000 r-xp 00000000 00:1c 287782 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/bin/java
    08052000-08053000 rwxp 00009000 00:1c 287782 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/bin/java
    08053000-08545000 rwxp 08053000 00:00 0
    a7210000-a7211000 ---p a7210000 00:00 0
    a7211000-a7c11000 rwxp a7211000 00:00 0
    a7c11000-a7cd7000 r-xp 00000000 00:1c 498129 /home/gdadev/tools/i686/rhel4.0/gcc-3.4.6/lib/libstdc++.so.6.0.3
    a7cd7000-a7cdc000 rwxp 000c6000 00:1c 498129 /home/gdadev/tools/i686/rhel4.0/gcc-3.4.6/lib/libstdc++.so.6.0.3
    a7cdc000-a7ce1000 rwxp a7cdc000 00:00 0
    a7ce1000-a7dc6000 r-xp 00000000 00:1f 2900632 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libstlport-mcg-5.1.so
    a7dc6000-a7de2000 rwxp 000e4000 00:1f 2900632 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libstlport-mcg-5.1.so
    a7de2000-a7de6000 rwxp a7de2000 00:00 0
    a7de6000-a7f5c000 r-xp 00000000 00:1f 2900652 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_vml_def.so
    a7f5c000-a7f6b000 rwxp 00175000 00:1f 2900652 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_vml_def.so
    a7f6b000-a8434000 r-xp 00000000 00:1f 2900523 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_lapack.so
    a8434000-a8436000 rwxp 004c9000 00:1f 2900523 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_lapack.so
    a8436000-a8492000 r-xp 00000000 00:1f 2900484 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_core.so
    a8492000-a8496000 rwxp 0005b000 00:1f 2900484 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_core.so
    a8496000-a84a4000 rwxp a8496000 00:00 0
    a84a4000-a8652000 r-xp 00000000 00:1f 2900521 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_intel_thread.so
    a8652000-a869f000 rwxp 001ae000 00:1f 2900521 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_intel_thread.so
    a869f000-a86a0000 rwxp a869f000 00:00 0
    a86a0000-a87d9000 r-xp 00000000 00:1f 2900517 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_intel.so
    a87d9000-a87dc000 rwxp 00139000 00:1f 2900517 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_intel.so
    a87dc000-a87e2000 rwxp a87dc000 00:00 0
    a87e2000-a87e9000 r-xp 00000000 00:1f 570263 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcstat_iblas.so
    a87e9000-a87ea000 rwxp 00006000 00:1f 570263 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcstat_iblas.so
    a87ea000-a8b08000 r-xp 00000000 00:1f 570239 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcstat.so
    a8b08000-a8b45000 rwxp 0031d000 00:1f 570239 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcstat.so
    a8b45000-a8b5e000 r-xp 00000000 00:1f 570822 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcmath_iblas.so
    a8b5e000-a8b5f000 rwxp 00019000 00:1f 570822 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcmath_iblas.so
    a8b5f000-a8c18000 r-xp 00000000 00:1f 570832 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcmath_scalar.so
    a8c18000-a8c19000 rwxp 000b8000 00:1f 570832 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcmath_scalar.so
    a8c19000-a8ee7000 r-xp 00000000 00:1f 570819 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcmath.so
    a8ee7000-a8ef6000 rwxp 002ce000 00:1f 570819 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcmath.so
    a8ef6000-a8ef7000 rwxp a8ef6000 00:00 0
    a8ef7000-a8f19000 r-xp 00000000 00:1f 2900421 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libboost_thread-mcg-1.34-stlport-5.1.so
    a8f19000-a8f1d000 rwxp 00022000 00:1f 2900421 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libboost_thread-mcg-1.34-stlport-5.1.so
    a8f1d000-aa180000 r-xp 00000000 00:1f 761178 /home/cartedav/workspaces/dev/mlclib/build/i686-rhel4.0-gcc3.4/checked-stlport-fine-full-multi-dynamic/libgda2mlclib.so
    aa180000-aa430000 rwxp 01263000 00:1f 761178 /home/cartedav/workspaces/dev/mlclib/build/i686-rhel4.0-gcc3.4/checked-stlport-fine-full-multi-dynamic/libgda2mlclib.so
    aa430000-aa53a000 rwxp aa430000 00:00 0
    aa53a000-ad779000 r-xp 00000000 00:1f 699688 /home/cartedav/workspaces/dev/mlclib/build/i686-rhel4.0-gcc3.4/checked-stlport-fine-full-multi-dynamic/libgda2ocean.so
    ad779000-ae56b000 rwxp 0323f000 00:1f 699688 /home/cartedav/workspaces/dev/mlclib/build/i686-rhel4.0-gcc3.4/checked-stlport-fine-full-multi-dynamic/libgda2ocean.so
    ae56b000-ae7a8000 rwxp ae56b000 00:00 0
    ae7a8000-ae886000 r-xp 00000000 00:1f 699721 /home/cartedav/workspaces/dev/mlclib/build/i686-rhel4.0-gcc3.4/checked-stlport-fine-full-multi-dynamic/libgda2generic.so
    ae886000-ae8a6000 rwxp 000de000 00:1f 699721 /home/cartedav/workspaces/dev/mlclib/build/i686-rhel4.0-gcc3.4/checked-stlport-fine-full-multi-dynamic/libgda2generic.so
    ae8a6000-ae8ac000 rwxp ae8a6000 00:00 0
    ae8ac000-ae904000 r-xp 00000000 00:1c 206109 /home/gdadev/builds/nightly/i686-rhel4.0-gcc3.4/libguide.so
    ae904000-ae909000 rwxp 00058000 00:1c 206109 /home/gdadev/builds/nightly/i686-rhel4.0-gcc3.4/libguide.so
    ae909000-ae90e000 rwxp ae909000 00:00 0
    ae90e000-aef20000 r-xp 00000000 00:1c 52046 /home/gdadev/builds/nightly/i686-rhel4.0-gcc3.4/libgda2rt.so
    aef20000-af01d000 rwxp 00612000 00:1c 52046 /home/gdadev/builds/nightly/i686-rhel4.0-gcc3.4/libgda2rt.so
    af01d000-af028000 rwxp af01d000 00:00 0
    af028000-af030000 r-xp 00000000 00:1c 497827 /home/gdadev/tools/i686/rhel4.0/gcc-3.4.6/lib/libgcc_s.so.1
    af030000-af031000 rwxp 00007000 00:1c 497827 /home/gdadev/tools/i686/rhel4.0/gcc-3.4.6/lib/libgcc_s.so.1
    af031000-af136000 r-xp 00000000 00:1c 205704 /home/gdadev/builds/nightly/i686-rhel4.0-gcc3.4/libgda2jni.so
    af136000-af158000 rwxp 00105000 00:1c 205704 /home/gdadev/builds/nightly/i686-rhel4.0-gcc3.4/libgda2jni.so
    af158000-af15d000 rwxp af158000 00:00 0
    af15d000-af15f000 r-xs 00009000 00:1c 205693 /home/gdadev/builds/nightly/i686-rhel4.0-gcc3.4/gda2.jar
    af15f000-af160000 ---p af15f000 00:00 0
    af160000-af1e0000 rwxp af160000 00:00 0
    af1e0000-af1e3000 ---p af1e0000 00:00 0
    af1e3000-af231000 rwxp af1e3000 00:00 0
    af231000-af234000 ---p af231000 00:00 0
    af234000-af2b2000 rwxp af234000 00:00 0
    af2b2000-af2b5000 ---p af2b2000 00:00 0
    af2b5000-af333000 rwxp af2b5000 00:00 0
    af333000-af336000 ---p af333000 00:00 0
    af336000-af384000 rwxp af336000 00:00 0
    af384000-af584000 r-xp 00000000 68:06 101636 /usr/lib/locale/locale-archive
    af584000-af587000 ---p af584000 00:00 0
    af587000-af5d5000 rwxp af587000 00:00 0
    af5d5000-af5d8000 ---p af5d5000 00:00 0
    af5d8000-af626000 rwxp af5d8000 00:00 0
    af626000-af627000 ---p af626000 00:00 0
    af627000-af6d7000 rwxp af627000 00:00 0
    af6d7000-af853000 r-xs 02c8f000 00:1c 925583 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/rt.jar
    af853000-af854000 ---p af853000 00:00 0
    af854000-af8d4000 rwxp af854000 00:00 0
    af8d4000-af8d5000 ---p af8d4000 00:00 0
    af8d5000-af955000 rwxp af8d5000 00:00 0
    af955000-af956000 ---p af955000 00:00 0
    af956000-af9d6000 rwxp af956000 00:00 0
    af9d6000-af9d7000 ---p af9d6000 00:00 0
    af9d7000-afa5f000 rwxp af9d7000 00:00 0
    afa5f000-afa77000 rwxp afa5f000 00:00 0
    afa77000-afae8000 rwxp afa77000 00:00 0
    afae8000-afc3f000 rwxp afae8000 00:00 0
    afc3f000-afc47000 rwxp afc3f000 00:00 0
    afc47000-afc5f000 rwxp afc47000 00:00 0
    afc5f000-afcd0000 rwxp afc5f000 00:00 0
    afcd0000-afe26000 rwxp afcd0000 00:00 0
    afe26000-afe51000 rwxp afe26000 00:00 0
    afe51000-afe5f000 rwxp afe51000 00:00 0
    afe5f000-b0e60000 rwxp afe5f000 00:00 0
    b0e60000-b3e60000 rwxp b0e60000 00:00 0
    b3e60000-c1ff0000 rwxp b3e60000 00:00 0
    c1ff0000-ecca0000 rwxp c1ff0000 00:00 0
    ecca0000-f21e0000 rwxp ecca0000 00:00 0
    f21e0000-f3e60000 rwxp f21e0000 00:00 0
    f3e6d000-f3e76000 rwxp f3e6d000 00:00 0
    f3e76000-f3f2d000 rwxp f3e76000 00:00 0
    f3f2d000-f416d000 rwxp f3f2d000 00:00 0
    f416d000-f6f2d000 rwxp f416d000 00:00 0
    f6f2d000-f6f3c000 r-xp 00000000 00:1c 172554 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/libzip.so
    f6f3c000-f6f3e000 rwxp 0000e000 00:1c 172554 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/libzip.so
    f6f3e000-f6f61000 r-xp 00000000 00:1c 172497 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/libjava.so
    f6f61000-f6f63000 rwxp 00023000 00:1c 172497 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/libjava.so
    f6f63000-f6f6e000 r-xp 00000000 00:1c 172493 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/libverify.so
    f6f6e000-f6f6f000 rwxp 0000b000 00:1c 172493 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/libverify.so
    f6f6f000-f6f77000 rwxs 00000000 68:06 247809 /tmp/hsperfdata_cartedav/23854
    f6f77000-f6f7f000 r-xp 00000000 68:06 213047 /lib/libnss_nis-2.3.4.so
    f6f7f000-f6f81000 rwxp 00007000 68:06 213047 /lib/libnss_nis-2.3.4.so
    f6f81000-f6f8a000 r-xp 00000000 68:06 213042 /lib/libnss_files-2.3.4.so
    f6f8a000-f6f8c000 rwxp 00008000 68:06 213042 /lib/libnss_files-2.3.4.so
    f6f93000-f6f99000 r-xp 00000000 00:1c 172254 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/native_threads/libhpi.so
    f6f99000-f6f9a000 rwxp 00006000 00:1c 172254 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/native_threads/libhpi.so
    f6f9a000-f6f9b000 rwxp f6f9a000 00:00 0
    f6f9b000-f6f9c000 ---p f6f9b000 00:00 0
    f6f9c000-f6f9f000 ---p f6f9c000 00:00 0
    f6f9f000-f6fef000 rwxp f6f9f000 00:00 0
    f6fef000-f6ff6000 r-xp 00000000 00:1c 172514 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/jli/libjli.so
    f6ff6000-f6ff8000 rwxp 00006000 00:1c 172514 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/jli/libjli.so
    f6fff000-f7000000 rwxp f6fff000 00:00 0
    feff9000-ff000000 rwxp feff9000 00:00 0
    ffffe000-fffff000 ---p 00000000 00:00 0
    VM Arguments:
    java_command: TestCrash AGRCRV.ODR.CC.xdr
    Launcher Type: SUN_STANDARD
    Environment Variables:
    JAVA_HOME=/home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03
    PATH=/home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/bin:/home/cartedav/bin:/home/gdadev/tools/i686/rhel4.0/j2sdk/bin:/home/gdadev/tools/i686/rhel4.0/gcc-3.4.6/bin:/home/gdadev/tools/i686/rhel4.0/bin:/home/cartedav/workspaces/dev/images/i686-rhel4.0-gcc3.4/bin:/home/gdadev/tools/i686/rhel4.0/j2sdk/bin:/home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/bin:/home/gdadev/tools/i686/rhel4.0/j2sdk/bin:/apps/linuxdev/bin:/usr/kerberos/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/quest/bin:/usr/X11R6/bin:
    LD_LIBRARY_PATH=/home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/server:/home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386:/home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/../lib/i386:/home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib:/home/gdadev/builds/nightly/i686-rhel4.0-gcc3.4/:/home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib:/home/gdadev/tools/i686/rhel4.0/j2sdk/lib:/home/gdadev/tools/i686/rhel4.0/gcc-3.4.6/lib:/home/gdadev/tools/i686/rhel4.0/lib:/home/cartedav/workspaces/dev/images/i686-rhel4.0-gcc3.4/lib:/home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib:/home/gdadev/tools/i686/rhel4.0/j2sdk/lib:/apps/linuxdev/lib::
    SHELL=/bin/csh
    DISPLAY=169.243.119.66:0.0
    HOSTTYPE=i386-linux
    OSTYPE=linux
    MACHTYPE=i386
    Signal Handlers:
    SIGSEGV: [libjvm.so+0x53c560], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
    SIGBUS: [libjvm.so+0x53c560], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
    SIGFPE: [libjvm.so+0x451a50], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
    SIGPIPE: [libjvm.so+0x451a50], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
    SIGILL: [libjvm.so+0x451a50], sa_mask[0]=0x00000000, sa_flags=0xe0000000, flags was changed from 0x10000004, consider using jsig library
    SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
    SIGUSR2: [libjvm.so+0x453a80], sa_mask[0]=0x00000000, sa_flags=0x10000004
    SIGHUP: [libjvm.so+0x4534a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
    SIGINT: [libjvm.so+0x4534a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
    SIGQUIT: [libjvm.so+0x4534a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
    SIGTERM: [libjvm.so+0x4534a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
    SIGUSR2: [libjvm.so+0x453a80], sa_mask[0]=0x00000000, sa_flags=0x10000004
    --------------- S Y S T E M ---------------
    OS:Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
    uname:Linux 2.6.9-42.0.2.ELhugemem #1 SMP Thu Aug 17 18:22:52 EDT 2006 i686
    libc:glibc 2.3.4 NPTL 2.3.4
    rlimit: STACK 10240k, CORE 0k, NPROC 274431, NOFILE 1024, AS infinity
    load average:0.28 0.17 0.16
    CPU:total 4 (2 cores per cpu, 1 threads per core) family 15 model 65 stepping 2, cmov, cx8, fxsr, mmx, sse, sse2, sse3, mmxext, 3dnow, 3dnowext
    Memory: 4k page, physical 16629672k(722080k free), swap 16779884k(16779740k free)
    vm_info: Java HotSpot(TM) Server VM (1.6.0_03-b05) for linux-x86, built on Sep 24 2007 22:32:39 by "java_re" with gcc 3.2.1-7a (J2SE release)

    Thanks very much for your advice. Unfortunately, stepping through the code doesn't help at all. The error occurs much later after the C code has been executed, whilst running the java code (which is just creating string objects to invoke the GC). The C code that we are executing is extremely simple - it consists of Sun's JNI example coupled with a sinlge call to the IMSL error options function:
    JNIEXPORT jbyteArray JNICALL Java_ReadFile_loadFile
    (JNIEnv * env, jobject jobj, jstring name) {
    printf("%s", "Setting imsl_error_options()...\n");
    imsl_error_options( IMSL_SET_SIGNAL_TRAPPING, 0, // Disable IMSL signal trapping - necessary for MT code.
    IMSL_SET_STOP, IMSL_FATAL, 0, // Disable stopping on FATAL errors
    IMSL_SET_STOP, IMSL_FATAL_IMMEDIATE, 0, // Disable stopping on FATAL_IMMEDIATE errors
    IMSL_SET_STOP, IMSL_TERMINAL, 0, // Disable stopping on TERMINAL errors
    IMSL_SET_PRINT, IMSL_FATAL, 1, // Enable printing on FATAL errors
    IMSL_SET_PRINT, IMSL_FATAL_IMMEDIATE, 1, // Enable printing on FATAL_IMMEDIATE errors
    IMSL_SET_PRINT, IMSL_TERMINAL, 1, // Enable printing on TERMINAL errors
    IMSL_SET_PRINT, IMSL_WARNING, 1, // Enable printing on WARNING errors
    IMSL_SET_PRINT, IMSL_WARNING_IMMEDIATE, 1, // Enable printing on WARNING_IMMEDIATE errors
    IMSL_SET_PRINT, IMSL_ALERT, 1, // Enable printing on TERMINAL errors
    IMSL_SET_PRINT, IMSL_NOTE, 1, // Enable printing on TERMINAL errors
    0 );
    caddr_t m;
    jbyteArray jb;
    jboolean iscopy;
    struct stat finfo;
    const char mfile = (env)->GetStringUTFChars(
    env, name, &iscopy);
    int fd = open(mfile, O_RDONLY);
    if (fd == -1) {
    printf("Could not open %s\n", mfile);
    lstat(mfile, &finfo);
    m = mmap((caddr_t) 0, finfo.st_size,
    PROT_READ, MAP_PRIVATE, fd, 0);
    if (m == (caddr_t)-1) {
    printf("Could not mmap %s\n", mfile);
    return(0);
    jb=(*env)->NewByteArray(env, finfo.st_size);
    (*env)->SetByteArrayRegion(env, jb, 0,
    finfo.st_size, (jbyte *)m);
    close(fd);
    (*env)->ReleaseStringUTFChars(env, name, mfile);
    return (jb);
    If I remove the call to imsl_error_options then there is no adverse behaviour - the Java loop completes ok (creating 1 trillion strings in the process) and the manual call the GC works fine. With the call to imsl, the execution gets to the string creation loop (in Java, after the C has been executed) and then it dies pretty quickly (presumably after the GC kicks in to clean up some of the strings).
    Here is the java code:
    import java.util.*;
    class ReadFile {
    //Native method declaration
    native byte[] loadFile(String name);
    //Load the library
    static {
    System.loadLibrary("nativelib");
    public static void main(String args[]) {
    byte buf[];
    //Create class instance
    ReadFile mappedFile=new ReadFile();
    //Call native method to load ReadFile.java
    buf=mappedFile.loadFile("ReadFile.java");
    //Print contents of ReadFile.java
    for(int i=0;i<buf.length;i++) {
    System.out.print((char)buf);
    System.out.print("Now running the string creation loop...\n");
    long block = 100000000;
    int numBlocks = 10;
    long loops = block * numBlocks;
    for (long i = 0; i < loops; i++) {
    // Create some objects that need disposal
    String.valueOf(i);
    if (i % block == 0) {
    System.out.print("Reached " + i + "\n");
    System.out.print("Now running the GC...\n");
    System.gc();

  • Manipulating C++ Objects in Java Through JNI

    Hi,
    I have some existing C++ classes objects that I would like to access through Java methods. However, if I use a java method to create an instance of a C++ object, and then I want to edit the state of that C++ object through java, how do I reference the correct C++ object.
    For example, if I have a C++ object called Ball, with two variables x and y representing its position and a constructor as well as set methods to set x and y. I then make a java class Ball with the same variables, constructor, and setter methods. But when the java constructor is called, I want the C++ version to be created, and when the java setter methods are called, I want the x and y of the correct C++ Ball instance to change.
    Is this is possible, and if so what are the steps needed?
    Thank you

    See example with C++ structure in
    http://www.sharewareplaza.com/Java-Platform-Invoke-API-Demo-version-download_49212.html

  • Instatiating a C++ class through JNI

    I am trying to instantiate a C++ class from within my Java program using JNI. I want to instatiate the class once, and then call a function within the class a number of times, in which the results obtained from the previous time the function was run would be used the next time the function was run. By instantiating tha class, my hope is that the variable values would stay within the class, and therefore would not need to be passed.
    It is not an option to pass the variable between the C++ and Java code, since I am working with matrices and JNI does not support passing matrices.
    Thanks!

    Here are some things to try:
    1) Just keep a static reference to the class in your DLL. It shouldn't be considered a local reference as Java classes would be, but if it is, maybe you can keep it as a global reference, which is used to keep a reference to a Java class between JNI calls.
    http://java.sun.com/docs/books/tutorial/native1.1/implementing/refs.html
    2) You could also pass the entire class back and forth as a byte array and then cast it when necessary, but that's potentially a lot of data to pass around.

  • Java Webservice calling C function through JNI

    I have a java class that is using the JNI to call native interface written in C. The called C function has dependencies in vendor supplied c function library in .lib (CAUEVT.LIB) format. I compiled the C function as .DLL file and put the .DLL file in the -Djava.library.path and same thing I put in the opmn.xml file for the Java option.
    Now, when I run the Java class from command line it works fine and makes call to the external system everything works fine.
    However, when I deploy the same as web service and try to test the web service, Java expects the external library also in .DLL format (The error message is "This application has failed to start because CAUEVT.dll was not found. Re-installing the application may fix this problem")
    If I look the application log file, I see the following error.
    java.lang.UnsatisfiedLinkError: D:\lib\CAEventLoggerImp.dll: Can't find dependent libraries
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1676)
    I am wondering if the java class can run without any problem, why is the webservice execution fails....?

    The problem was that when Java loads the shared DLL we create from the java.library.path setting, but if the loaded DLL refers to any other DLL, it expects it from the System path. And for some reason, OC4J, doesn't expose all the system path unless entered in the Evnironment Variable explicitly in the Administration tab in OEM., server properties in the OEM. (opmn.xml)
    IT works fine after these changes.

Maybe you are looking for