Re: [osg-users] Building JNI wrapper for OSGdem
Hi Sean,
Not sure of what's the problem there. I think you need to debug the
problem by yourself. When we need to debug JNI code we build all in
debug (or release with debug info) and use the 'Attach to process'
functionality in debuggers. Attaching to java process and then setting
the breakpoint in JNI code you can debug and spot the problem. It's a
little bit tricky but sometimes necessary :).
Anyway we made something similar inside osgvp code. Take a look at:
-
https://devel.gvsig.org/svn/osgvp/trunk/wrappers/java/libjni-osgvpcore/src/main/native/josgvpcore/UpdateNodeListener.cpp
and this piece of code:
// code in Java
package org.gvsig.osgvp.util;
import org.gvsig.osgvp.core.osg.Node;
public interface UpdateNodeListener {
public void update(Node node);
}
// other code in c
JNIEXPORT void JNICALL
Java_org_gvsig_osgvp_core_osg_Node_native_1setUpdateListener(JNIEnv
*env, jclass, jlong cptr, jobject updateListener)
{
osg::Node *node = reinterpret_castosg::Node*(cptr);
if(node==0) return;
JavaVM *vm;
env-GetJavaVM(vm);
jclass cls = env-GetObjectClass(updateListener);
jmethodID jniExecMethod = env-GetMethodID(cls, update,
(Lorg/gvsig/osgvp/core/osg/Node;)V);
if (jniExecMethod == 0)
{
std::cerr UpdateNodeListener: not update(Node node) method
found! std::endl;
return;
}
node-setUpdateCallback(new
osgvp::core::UpdateListener(vm,cls,env-NewGlobalRef(updateListener),jniExecMethod));
}
Good luck,
Rafa.
2012/5/9 Sean K sk92...@gmail.com:
Thank you for the background information.
There is different JNI issue that I am encountering.
I was invoking a static function member from the native code.
At this point, I dont mind using a static function member, but for
thread safety in subsequent release, I need to switch it to use an
instance function member.
I saw the documentation about using non-static function members. And
I think I updated the code to use it correctly. But it encounters a
runtime crash in the jvm.
the crash and java and native code fragments follows:
static callback invoked from native: 7870.00
static callback passing integer invoked.
333
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (jni.cpp:947), pid=1852, tid=5864
# Error: ShouldNotReachHere()
#
# JRE version: 6.0_32-b05
# Java VM: Java HotSpot(TM) Client VM (20.7-b02 mixed mode, sharing
windows-x86 )
# An error report file with more information is saved as:
# C:\Users\sk\workspace\osg\osgnativelib\hs_err_pid1852.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (jni.cpp:947), pid=1852, tid=5864
# Error: ShouldNotReachHere()
#
# JRE version: 6.0_32-b05
# Java VM: Java HotSpot(TM) Client VM (20.7-b02 mixed mode, sharing
windows-x86 )
# 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 (0x0264a800): JavaThread main [_thread_in_vm,
id=5864, stack(0x0055,0x005a)]
Stack: [0x0055,0x005a], sp=0x0059f878, free space=318k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
code)
V [jvm.dll+0x13373a]
V [jvm.dll+0x12e6db]
V [jvm.dll+0x9529c]
V [jvm.dll+0x95a27]
V [jvm.dll+0x9890c]
C [HelloWorldWin32Library.dll+0x116d3] JNIEnv_::CallVoidMethod+0x43
C [HelloWorldWin32Library.dll+0x14274]
Java_com_foo_osgjni_core_MathFuncTest_Multiple+0x114
j com.foo.osgjni.core.MathFuncTest.Multiple(DD)D+0
j com.foo.osgjni.core.MathFuncTest.main([Ljava/lang/String;)V+15
v ~StubRoutines::call_stub
V [jvm.dll+0xfad4b]
V [jvm.dll+0x18c421]
V [jvm.dll+0xfadcd]
V [jvm.dll+0x95836]
V [jvm.dll+0x9d673]
C [javaw.exe+0x2155]
C [javaw.exe+0x8614]
C [kernel32.dll+0x1339a] BaseThreadInitThunk+0x12
C [ntdll.dll+0x39ed2] RtlInitializeExceptionChain+0x63
C [ntdll.dll+0x39ea5] RtlInitializeExceptionChain+0x36
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j com.foo.osgjni.core.MathFuncTest.Multiple(DD)D+0
j com.foo.osgjni.core.MathFuncTest.main([Ljava/lang/String;)V+15
v ~StubRoutines::call_stub
#define STATICMETHODFUNCTIONNAME callback
#define FUNCTION_SIGNATURE (Ljava/lang/String;)V
#define STATICCALLNUMBERFUNCTIONNAME callnumber
#define STATICCALLNUMBERFUNCTION_SIGNATURE (I)V
#define INSTANCEMETHODFUNCTIONNAME callbackInstance
#define INSTANCE_FUNCTION_SIGNATURE (I)V
JNIEXPORT jdouble JNICALL Java_osgjni_core_MathFuncTest_Multiple
(JNIEnv *penv, jobject obj, jdouble left, jdouble right) {
jdouble product = left * right;
jclass cls = penv-GetObjectClass(obj);
jmethodID midStatic = penv-GetStaticMethodID(cls,
Re: [osg-users] Building JNI wrapper for OSGdem
Hi Sean,
The first I spotted watching your stacktrace is that your are mixing
debug with release libraries. AFAIK on windows mixing debug and
release always gives problems, so the best you can do if you want to
debug your code is build osg in debug or build your code in release
with debug symbols.
Cheers,
Rafa.
2012/5/9 Sean K sk92...@gmail.com:
Hi,
I took a look at your code.
It looks good. Since the *.h headers from OSG and VPB DLLs are not
intended for java JNI invocation, I see that your code has built is
own DLL which in turn uses the OSG runtimes.
I am taking this similar approach -- as follow...
Since I want to do what osgdem.exe does but want to make that
accessible from a java application, I wrote a C DLL on Windows that is
invoked by my java class.
When that DLL has all the includes and DLL lib imported linked to it
(same build dependency as osgdem.exe -- but it is a DLL instead of a
EXE), the java class can invoke that function in that DLL -- i put
some test code in that DLL.
Then I copied most of the code from osgdem.cpp into the main function
of my DLL.
I re-initialize the arguments etc from my entry point so that it
mimics osgdem.cpp as much as possible -- at least at this version.
Now, when I invoke my DLL which should do the same essential thing
that osgdem.exe does, it encounters a java hotspot exception access
violation.
here is the content of that log file it is generated by jvm.
(i hide the name of the company and myself to protect the privacy)
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x5ca957aa, pid=2036,
tid=5660
#
# JRE version: 6.0_32-b05
# Java VM: Java HotSpot(TM) Client VM (20.7-b02 mixed mode windows-x86 )
# Problematic frame:
# C [MSVCR100D.dll+0x1157aa]
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
--- T H R E A D ---
Current thread (0x0211a800): JavaThread main [_thread_in_native,
id=5660, stack(0x0022,0x0027)]
siginfo: ExceptionCode=0xc005, reading address 0xccc0
Registers:
EAX=0xccac, EBX=0x44b618c8, ECX=0xccac, EDX=0x0004
ESP=0x0026e788, EBP=0x0026e7b4, ESI=0x0026ea8c, EDI=0x0026e898
EIP=0x5ca957aa, EFLAGS=0x00010286
Top of Stack: (sp=0x0026e788)
0x0026e788: 4fc8e4ec 0026e898 0026ea8c 44b618c8
0x0026e798: ccac fffe 0026e33c 0026ea78
0x0026e7a8: 5ca99320 13430fa0 0026e898
0x0026e7b8: 5e7d271c 0026e98c 0026ea8c
0x0026e7c8: 44b618c8
0x0026e7d8:
0x0026e7e8:
0x0026e7f8:
Instructions: (pc=0x5ca957aa)
0x5ca9578a: 00 00 00 6a 04 e8 5c 3f f3 ff 83 c4 04 c7 45 fc
0x5ca9579a: 00 00 00 00 8b 45 08 83 e8 20 89 45 e4 8b 4d e4
0x5ca957aa: 8b 51 14 81 e2 ff ff 00 00 83 fa 04 74 41 8b 45
0x5ca957ba: e4 83 78 14 01 74 38 8b 4d e4 8b 51 14 81 e2 ff
Register to memory mapping:
EAX=0xccac is an unknown value
EBX=0x44b618c8 is an oop
{method}
- klass: {other class}
ECX=0xccac is an unknown value
EDX=0x0004 is an unknown value
ESP=0x0026e788 is pointing into the stack for thread: 0x0211a800
EBP=0x0026e7b4 is pointing into the stack for thread: 0x0211a800
ESI=0x0026ea8c is pointing into the stack for thread: 0x0211a800
EDI=0x0026e898 is pointing into the stack for thread: 0x0211a800
Stack: [0x0022,0x0027], sp=0x0026e788, free space=313k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
code)
C [MSVCR100D.dll+0x1157aa] operator delete+0x5a
C [libosggen.dll+0x2271c] std::allocatorchar::deallocate+0x2c
C [libosggen.dll+0x208f5]
std::basic_stringchar,std::char_traitschar,std::allocatorchar
::_Tidy+0x75
C [libosggen.dll+0x197d5]
std::basic_stringchar,std::char_traitschar,std::allocatorchar
::~basic_stringchar,std::char_traitschar,std::allocatorchar
+0x55
C [libosggen.dll+0x173a9] StartOsgDem+0x1ec9
C [libosggen.dll+0x29244]
Java_foo_osgjni_core_GeneratorOSGImpl_startOsgDem+0xe4
j
com.foo.osgjni.core.GeneratorOSGImpl.startOsgDem(DDLjava/lang/String;Ljava/lang/String;Ljava/lang/String;)Z+0
j
com.foo.osgjni.core.GeneratorOSGImpl.start(Ljava/io/File;Ljava/io/File;Ljava/io/File;Lcom/foo/osgjni/core/IOSGHandler;)Z+24
j com.foo.osgjni.core.GeneratorOSGImplTest.main([Ljava/lang/String;)V+67
v ~StubRoutines::call_stub
V [jvm.dll+0xfad4b]
V [jvm.dll+0x18c421]
V [jvm.dll+0xfadcd]
V [jvm.dll+0x95836]
V [jvm.dll+0x9d778]
V [jvm.dll+0xaf22b]
C [javaw.exe+0x2155]
C [javaw.exe+0x8614]
C [kernel32.dll+0x1339a] BaseThreadInitThunk+0x12
C [ntdll.dll+0x39ed2] RtlInitializeExceptionChain+0x63
C [ntdll.dll+0x39ea5]
Re: [osg-users] Building JNI wrapper for OSGdem
Hi Rafa
Thank you so much for looking at the problem -- having a second set of
eyes look at a problem is so valuable.
You were right -- The OSG and VPB -- I was using release builds. But
my own DLL -- I had it in the DEBUG build.
After I changed to RELEASE build, the crash did not happen anymore --
and my DLL was able to successfully build the output OSG file.
Thank you for helping.
Just curious though -- what is the issue behind mixing debug and
release binaries that causes something like this to crash? I noticed
in the original crash that it was involved in the c++ deconstructor
for strings or some other C++ POJO. I am thinking about what could
have been implemented in those destructors or runtime libraries that
is confused with either debug or release binaries.
Maybe the function signatures are switched between debug or release
mode? That seems very dangerous. Maybe the size of the heap
objects used for strings are different between the release and debug?
Just curious why the mix up for non-debug and debug libraries causes
this kind of crash.
On Wed, May 9, 2012 at 12:38 AM, Rafa Gaitan rafa.gai...@gmail.com wrote:
Hi Sean,
The first I spotted watching your stacktrace is that your are mixing
debug with release libraries. AFAIK on windows mixing debug and
release always gives problems, so the best you can do if you want to
debug your code is build osg in debug or build your code in release
with debug symbols.
Cheers,
Rafa.
2012/5/9 Sean K sk92...@gmail.com:
Hi,
I took a look at your code.
It looks good. Since the *.h headers from OSG and VPB DLLs are not
intended for java JNI invocation, I see that your code has built is
own DLL which in turn uses the OSG runtimes.
I am taking this similar approach -- as follow...
Since I want to do what osgdem.exe does but want to make that
accessible from a java application, I wrote a C DLL on Windows that is
invoked by my java class.
When that DLL has all the includes and DLL lib imported linked to it
(same build dependency as osgdem.exe -- but it is a DLL instead of a
EXE), the java class can invoke that function in that DLL -- i put
some test code in that DLL.
Then I copied most of the code from osgdem.cpp into the main function
of my DLL.
I re-initialize the arguments etc from my entry point so that it
mimics osgdem.cpp as much as possible -- at least at this version.
Now, when I invoke my DLL which should do the same essential thing
that osgdem.exe does, it encounters a java hotspot exception access
violation.
here is the content of that log file it is generated by jvm.
(i hide the name of the company and myself to protect the privacy)
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x5ca957aa, pid=2036,
tid=5660
#
# JRE version: 6.0_32-b05
# Java VM: Java HotSpot(TM) Client VM (20.7-b02 mixed mode windows-x86 )
# Problematic frame:
# C [MSVCR100D.dll+0x1157aa]
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
--- T H R E A D ---
Current thread (0x0211a800): JavaThread main [_thread_in_native,
id=5660, stack(0x0022,0x0027)]
siginfo: ExceptionCode=0xc005, reading address 0xccc0
Registers:
EAX=0xccac, EBX=0x44b618c8, ECX=0xccac, EDX=0x0004
ESP=0x0026e788, EBP=0x0026e7b4, ESI=0x0026ea8c, EDI=0x0026e898
EIP=0x5ca957aa, EFLAGS=0x00010286
Top of Stack: (sp=0x0026e788)
0x0026e788: 4fc8e4ec 0026e898 0026ea8c 44b618c8
0x0026e798: ccac fffe 0026e33c 0026ea78
0x0026e7a8: 5ca99320 13430fa0 0026e898
0x0026e7b8: 5e7d271c 0026e98c 0026ea8c
0x0026e7c8: 44b618c8
0x0026e7d8:
0x0026e7e8:
0x0026e7f8:
Instructions: (pc=0x5ca957aa)
0x5ca9578a: 00 00 00 6a 04 e8 5c 3f f3 ff 83 c4 04 c7 45 fc
0x5ca9579a: 00 00 00 00 8b 45 08 83 e8 20 89 45 e4 8b 4d e4
0x5ca957aa: 8b 51 14 81 e2 ff ff 00 00 83 fa 04 74 41 8b 45
0x5ca957ba: e4 83 78 14 01 74 38 8b 4d e4 8b 51 14 81 e2 ff
Register to memory mapping:
EAX=0xccac is an unknown value
EBX=0x44b618c8 is an oop
{method}
- klass: {other class}
ECX=0xccac is an unknown value
EDX=0x0004 is an unknown value
ESP=0x0026e788 is pointing into the stack for thread: 0x0211a800
EBP=0x0026e7b4 is pointing into the stack for thread: 0x0211a800
ESI=0x0026ea8c is pointing into the stack for thread: 0x0211a800
EDI=0x0026e898 is pointing into the stack for thread: 0x0211a800
Stack: [0x0022,0x0027], sp=0x0026e788, free space=313k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
code)
C
Re: [osg-users] Building JNI wrapper for OSGdem
On 05/09/2012 12:39 PM, Sean K wrote: Hi Rafa Thank you so much for looking at the problem -- having a second set of eyes look at a problem is so valuable. You were right -- The OSG and VPB -- I was using release builds. But my own DLL -- I had it in the DEBUG build. After I changed to RELEASE build, the crash did not happen anymore -- and my DLL was able to successfully build the output OSG file. Thank you for helping. Just curious though -- what is the issue behind mixing debug and release binaries that causes something like this to crash? I noticed in the original crash that it was involved in the c++ deconstructor for strings or some other C++ POJO. I am thinking about what could have been implemented in those destructors or runtime libraries that is confused with either debug or release binaries. Maybe the function signatures are switched between debug or release mode? That seems very dangerous. Maybe the size of the heap objects used for strings are different between the release and debug? Just curious why the mix up for non-debug and debug libraries causes this kind of crash. The main source of the issue is the Microsoft C runtime library. The debug version of the CRT and the release version are two separate DLLs and they occupy different areas in memory when loaded. The heap managers are also very different (the debug heap includes a lot of extra data to help debug memory allocation/initialization issues), so if you create an object on the debug heap and later free it from the release heap, you'll have heap corruption. Details about the issue are here: http://msdn.microsoft.com/en-us/library/ms235460%28v=vs.80%29.aspx There are also likely to be countless differences in the code itself (ever seen #ifdef _DEBUG in the header files?) The topic has been discussed many, many times on this list, too. You can skim through the archives for more info. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Building JNI wrapper for OSGdem
Thank you for the background information.
There is different JNI issue that I am encountering.
I was invoking a static function member from the native code.
At this point, I dont mind using a static function member, but for
thread safety in subsequent release, I need to switch it to use an
instance function member.
I saw the documentation about using non-static function members. And
I think I updated the code to use it correctly. But it encounters a
runtime crash in the jvm.
the crash and java and native code fragments follows:
static callback invoked from native: 7870.00
static callback passing integer invoked.
333
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (jni.cpp:947), pid=1852, tid=5864
# Error: ShouldNotReachHere()
#
# JRE version: 6.0_32-b05
# Java VM: Java HotSpot(TM) Client VM (20.7-b02 mixed mode, sharing
windows-x86 )
# An error report file with more information is saved as:
# C:\Users\sk\workspace\osg\osgnativelib\hs_err_pid1852.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (jni.cpp:947), pid=1852, tid=5864
# Error: ShouldNotReachHere()
#
# JRE version: 6.0_32-b05
# Java VM: Java HotSpot(TM) Client VM (20.7-b02 mixed mode, sharing
windows-x86 )
# 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 (0x0264a800): JavaThread main [_thread_in_vm,
id=5864, stack(0x0055,0x005a)]
Stack: [0x0055,0x005a], sp=0x0059f878, free space=318k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [jvm.dll+0x13373a]
V [jvm.dll+0x12e6db]
V [jvm.dll+0x9529c]
V [jvm.dll+0x95a27]
V [jvm.dll+0x9890c]
C [HelloWorldWin32Library.dll+0x116d3] JNIEnv_::CallVoidMethod+0x43
C [HelloWorldWin32Library.dll+0x14274]
Java_com_foo_osgjni_core_MathFuncTest_Multiple+0x114
j com.foo.osgjni.core.MathFuncTest.Multiple(DD)D+0
j com.foo.osgjni.core.MathFuncTest.main([Ljava/lang/String;)V+15
v ~StubRoutines::call_stub
V [jvm.dll+0xfad4b]
V [jvm.dll+0x18c421]
V [jvm.dll+0xfadcd]
V [jvm.dll+0x95836]
V [jvm.dll+0x9d673]
C [javaw.exe+0x2155]
C [javaw.exe+0x8614]
C [kernel32.dll+0x1339a] BaseThreadInitThunk+0x12
C [ntdll.dll+0x39ed2] RtlInitializeExceptionChain+0x63
C [ntdll.dll+0x39ea5] RtlInitializeExceptionChain+0x36
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j com.foo.osgjni.core.MathFuncTest.Multiple(DD)D+0
j com.foo.osgjni.core.MathFuncTest.main([Ljava/lang/String;)V+15
v ~StubRoutines::call_stub
#define STATICMETHODFUNCTIONNAME callback
#define FUNCTION_SIGNATURE (Ljava/lang/String;)V
#define STATICCALLNUMBERFUNCTIONNAME callnumber
#define STATICCALLNUMBERFUNCTION_SIGNATURE (I)V
#define INSTANCEMETHODFUNCTIONNAME callbackInstance
#define INSTANCE_FUNCTION_SIGNATURE (I)V
JNIEXPORT jdouble JNICALL Java_osgjni_core_MathFuncTest_Multiple
(JNIEnv *penv, jobject obj, jdouble left, jdouble right) {
jdouble product = left * right;
jclass cls = penv-GetObjectClass(obj);
jmethodID midStatic = penv-GetStaticMethodID(cls,
STATICMETHODFUNCTIONNAME, FUNCTION_SIGNATURE);
jmethodID midStaticNumber = penv-GetStaticMethodID(cls,
STATICCALLNUMBERFUNCTIONNAME, STATICCALLNUMBERFUNCTION_SIGNATURE);
jmethodID midInstance = penv-GetMethodID(cls,
INSTANCEMETHODFUNCTIONNAME, INSTANCE_FUNCTION_SIGNATURE);
char buffer[20];
sprintf(buffer, %5.2f, product);
jstring jstr = penv-NewStringUTF(buffer);
if (midStatic != 0) {
penv-CallStaticVoidMethod(cls, midStatic, jstr);
}
if (midStaticNumber != 0) {
penv-CallStaticVoidMethod(cls, midStaticNumber, 333);
}
if (midInstance != 0) {
penv-CallVoidMethod(cls, midInstance, 10);
}
return product;
}
public class MathFuncTest {
native double Multiple (double left, double right);
static {
System.load(c:\\DEV\\src\\test\\Debug\\HelloWorldWin32Library.dll);
}
/**
* this is used for the static function member test.
* @param msg
*/
public static void callnumber (int number) {
System.out.println(static callback passing integer invoked.);
System.out.println(number);
}
/**
* this is used for the static function member test.
* @param msg
*
*
*/
public static void callback(String msg) {
//System.out.println(msg);
if (msg != null){
System.out.println(static callback invoked from
native: + msg);
}
}
Re: [osg-users] Building JNI wrapper for OSGdem
Hi,
I took a look at your code.
It looks good. Since the *.h headers from OSG and VPB DLLs are not
intended for java JNI invocation, I see that your code has built is
own DLL which in turn uses the OSG runtimes.
I am taking this similar approach -- as follow...
Since I want to do what osgdem.exe does but want to make that
accessible from a java application, I wrote a C DLL on Windows that is
invoked by my java class.
When that DLL has all the includes and DLL lib imported linked to it
(same build dependency as osgdem.exe -- but it is a DLL instead of a
EXE), the java class can invoke that function in that DLL -- i put
some test code in that DLL.
Then I copied most of the code from osgdem.cpp into the main function
of my DLL.
I re-initialize the arguments etc from my entry point so that it
mimics osgdem.cpp as much as possible -- at least at this version.
Now, when I invoke my DLL which should do the same essential thing
that osgdem.exe does, it encounters a java hotspot exception access
violation.
here is the content of that log file it is generated by jvm.
(i hide the name of the company and myself to protect the privacy)
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x5ca957aa, pid=2036, tid=5660
#
# JRE version: 6.0_32-b05
# Java VM: Java HotSpot(TM) Client VM (20.7-b02 mixed mode windows-x86 )
# Problematic frame:
# C [MSVCR100D.dll+0x1157aa]
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
--- T H R E A D ---
Current thread (0x0211a800): JavaThread main [_thread_in_native,
id=5660, stack(0x0022,0x0027)]
siginfo: ExceptionCode=0xc005, reading address 0xccc0
Registers:
EAX=0xccac, EBX=0x44b618c8, ECX=0xccac, EDX=0x0004
ESP=0x0026e788, EBP=0x0026e7b4, ESI=0x0026ea8c, EDI=0x0026e898
EIP=0x5ca957aa, EFLAGS=0x00010286
Top of Stack: (sp=0x0026e788)
0x0026e788: 4fc8e4ec 0026e898 0026ea8c 44b618c8
0x0026e798: ccac fffe 0026e33c 0026ea78
0x0026e7a8: 5ca99320 13430fa0 0026e898
0x0026e7b8: 5e7d271c 0026e98c 0026ea8c
0x0026e7c8: 44b618c8
0x0026e7d8:
0x0026e7e8:
0x0026e7f8:
Instructions: (pc=0x5ca957aa)
0x5ca9578a: 00 00 00 6a 04 e8 5c 3f f3 ff 83 c4 04 c7 45 fc
0x5ca9579a: 00 00 00 00 8b 45 08 83 e8 20 89 45 e4 8b 4d e4
0x5ca957aa: 8b 51 14 81 e2 ff ff 00 00 83 fa 04 74 41 8b 45
0x5ca957ba: e4 83 78 14 01 74 38 8b 4d e4 8b 51 14 81 e2 ff
Register to memory mapping:
EAX=0xccac is an unknown value
EBX=0x44b618c8 is an oop
{method}
- klass: {other class}
ECX=0xccac is an unknown value
EDX=0x0004 is an unknown value
ESP=0x0026e788 is pointing into the stack for thread: 0x0211a800
EBP=0x0026e7b4 is pointing into the stack for thread: 0x0211a800
ESI=0x0026ea8c is pointing into the stack for thread: 0x0211a800
EDI=0x0026e898 is pointing into the stack for thread: 0x0211a800
Stack: [0x0022,0x0027], sp=0x0026e788, free space=313k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [MSVCR100D.dll+0x1157aa] operator delete+0x5a
C [libosggen.dll+0x2271c] std::allocatorchar::deallocate+0x2c
C [libosggen.dll+0x208f5]
std::basic_stringchar,std::char_traitschar,std::allocatorchar
::_Tidy+0x75
C [libosggen.dll+0x197d5]
std::basic_stringchar,std::char_traitschar,std::allocatorchar
::~basic_stringchar,std::char_traitschar,std::allocatorchar
+0x55
C [libosggen.dll+0x173a9] StartOsgDem+0x1ec9
C [libosggen.dll+0x29244]
Java_foo_osgjni_core_GeneratorOSGImpl_startOsgDem+0xe4
j
com.foo.osgjni.core.GeneratorOSGImpl.startOsgDem(DDLjava/lang/String;Ljava/lang/String;Ljava/lang/String;)Z+0
j
com.foo.osgjni.core.GeneratorOSGImpl.start(Ljava/io/File;Ljava/io/File;Ljava/io/File;Lcom/foo/osgjni/core/IOSGHandler;)Z+24
j com.foo.osgjni.core.GeneratorOSGImplTest.main([Ljava/lang/String;)V+67
v ~StubRoutines::call_stub
V [jvm.dll+0xfad4b]
V [jvm.dll+0x18c421]
V [jvm.dll+0xfadcd]
V [jvm.dll+0x95836]
V [jvm.dll+0x9d778]
V [jvm.dll+0xaf22b]
C [javaw.exe+0x2155]
C [javaw.exe+0x8614]
C [kernel32.dll+0x1339a] BaseThreadInitThunk+0x12
C [ntdll.dll+0x39ed2] RtlInitializeExceptionChain+0x63
C [ntdll.dll+0x39ea5] RtlInitializeExceptionChain+0x36
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j
com.foo.osgjni.core.GeneratorOSGImpl.startOsgDem(DDLjava/lang/String;Ljava/lang/String;Ljava/lang/String;)Z+0
j
com.foo.osgjni.core.GeneratorOSGImpl.start(Ljava/io/File;Ljava/io/File;Ljava/io/File;Lcom/foo/osgjni/core/IOSGHandler;)Z+24
j com.foo.osgjni.core.GeneratorOSGImplTest.main([Ljava/lang/String;)V+67
v ~StubRoutines::call_stub
Re: [osg-users] Building JNI wrapper for OSGdem
thanks!
On May 4, 2012 4:02 PM, Rafa Gaitan rafa.gai...@gmail.com wrote:
Hi Sean,
We have made lot of JNI stuff in osgVirtualPlanets. Is a the GIS
library for gvSIG3D that we developed.
svn co https://devel.gvsig.org/svn/osgvp/trunk
The wrappers are inside wrappers directory. Is not exactly what are
you looking for, but maybe you find inspiration in the code.
Cheers,
Rafa.
2012/5/5 Sean K sk92...@gmail.com:
I am looking to build a Java wrapper with JNI around the code which
basically exists inside of osgdem.cpp.
The bulk of that code resides in vpb.dll and osgDB.dll.
Anybody tried this? I am guessing others have already done this.
I also want to send back the console output back to the java caller
via a java callback
basically,
if I wrote a JNI class named OsgDem.java
I would write code my OsgDemTest.java like this:
class MyOsgHandler implements OsgHander {
@Override
void OnStatus (String output) {
System.out.println(output);
}
@Override
void OnEnd (boolean success, String resultMsg) {
if (success) {
System.out.println(good);
} else {
System.out.println(bad);
}
}
}
@Test
public void testOsgdem() {
Properties global = new Properties();
global.load(osgdem.properties);
OsgDem generator = new OsgDem(global);
generator.start(handler, inputTerrainPath,
inputTexturePath, outputFilePath);
}
Anybody have any JNI code that I can start with to build my OsdDem?
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Rafael Gaitán Linares
CTO at Mirage Technologies S.L - http://www.mirage-tech.com
gvSIG3D Developer - http://gvsig3d.blogspot.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Building JNI wrapper for OSGdem
I am looking to build a Java wrapper with JNI around the code which
basically exists inside of osgdem.cpp.
The bulk of that code resides in vpb.dll and osgDB.dll.
Anybody tried this? I am guessing others have already done this.
I also want to send back the console output back to the java caller
via a java callback
basically,
if I wrote a JNI class named OsgDem.java
I would write code my OsgDemTest.java like this:
class MyOsgHandler implements OsgHander {
@Override
void OnStatus (String output) {
System.out.println(output);
}
@Override
void OnEnd (boolean success, String resultMsg) {
if (success) {
System.out.println(good);
} else {
System.out.println(bad);
}
}
}
@Test
public void testOsgdem() {
Properties global = new Properties();
global.load(osgdem.properties);
OsgDem generator = new OsgDem(global);
generator.start(handler, inputTerrainPath,
inputTexturePath, outputFilePath);
}
Anybody have any JNI code that I can start with to build my OsdDem?
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Building JNI wrapper for OSGdem
Hi Sean,
We have made lot of JNI stuff in osgVirtualPlanets. Is a the GIS
library for gvSIG3D that we developed.
svn co https://devel.gvsig.org/svn/osgvp/trunk
The wrappers are inside wrappers directory. Is not exactly what are
you looking for, but maybe you find inspiration in the code.
Cheers,
Rafa.
2012/5/5 Sean K sk92...@gmail.com:
I am looking to build a Java wrapper with JNI around the code which
basically exists inside of osgdem.cpp.
The bulk of that code resides in vpb.dll and osgDB.dll.
Anybody tried this? I am guessing others have already done this.
I also want to send back the console output back to the java caller
via a java callback
basically,
if I wrote a JNI class named OsgDem.java
I would write code my OsgDemTest.java like this:
class MyOsgHandler implements OsgHander {
@Override
void OnStatus (String output) {
System.out.println(output);
}
@Override
void OnEnd (boolean success, String resultMsg) {
if (success) {
System.out.println(good);
} else {
System.out.println(bad);
}
}
}
@Test
public void testOsgdem() {
Properties global = new Properties();
global.load(osgdem.properties);
OsgDem generator = new OsgDem(global);
generator.start(handler, inputTerrainPath,
inputTexturePath, outputFilePath);
}
Anybody have any JNI code that I can start with to build my OsdDem?
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Rafael Gaitán Linares
CTO at Mirage Technologies S.L - http://www.mirage-tech.com
gvSIG3D Developer - http://gvsig3d.blogspot.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
