[vtkusers] Bad memory access in VTK+Java on Mac OS X 10.2.4 (gdb debug info included)

Jeff Lee jeff at cdnorthamerica.com
Fri Mar 21 15:03:58 EST 2003


I remember this being a problem with vtkObject and reference counting 
some time ago, but it was fixed.  What version of vtk are you using?
-Jeff

Surajit Nundy wrote:

> Hello,
>     I have been hitting my head against this problem for some time 
> now.  This is a working build of vtk+Java (all classes tested are 
> working except vtkPanel) but when I try and set the input of a 
> vtkPolyDataMapper to a vtkConeSource, I get the following crash (debug 
> output is below).
> It would help me immensely if someone could tell me if this is a known 
> bug and/or what I need to change in the source code to fix it.
>
> Thanks,
> Surajit Nundy
>
>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> 0x0e29b810 in vtkHashTable::AddHashEntry(void*, void*) ()
>> (gdb) where
>> #0  0x0e29b810 in vtkHashTable::AddHashEntry(void*, void*) ()
>> #1  0x0e29bc34 in vtkJavaRegisterCastFunction(JNIEnv_*, _jobject*, 
>> int, void*) ()
>> #2  0x0e26ec00 in Java_vtk_vtkPolyData_VTKCastInit ()
>> #3  0x089e5678 in ?? ()
>> #4  0xa2843c38 in typeinfo name for std::bad_exception ()
>> #5  0x92838bdc in JVM_CurrentTimeMillis ()
>> #6  0x92872ed4 in JVM_GetCPClassNameUTF ()
>> #7  0x9287a3b8 in JVM_GetCPMethodModifiers ()
>> #8  0x9299cd40 in jio_vsnprintf ()
>> #9  0x0e61f464 in JNIEnv_::CallVoidMethod(_jobject*, _jmethodID*, 
>> ...) ()
>> #10 0x0e5d949c in vtkJavaCreateNewJavaStub(JNIEnv_*, char const*, 
>> void*) ()
>> #11 0x0e5d93b0 in vtkJavaCreateNewJavaStubForObject(JNIEnv_*, 
>> vtkObject*) ()
>> #12 0x0e0e58f4 in Java_vtk_vtkPolyDataSource_GetOutput_12 ()
>> #13 0x089e5678 in ?? ()
>> #14 0x089e35cc in ?? ()
>> #15 0xa2843c38 in typeinfo name for std::bad_exception ()
>> #16 0x92838bdc in JVM_CurrentTimeMillis ()
>> #17 0x92872ed4 in JVM_GetCPClassNameUTF ()
>> #18 0x9287a3b8 in JVM_GetCPMethodModifiers ()
>> #19 0x92998060 in jio_vsnprintf ()
>> #20 0x017c8f3c in mljCallObjectMethodA (obj=0x23cd500, 
>> method=0xa2831a24, args=0x2391d30) at japi.c:1375
>> #21 0x017d3bb8 in javaExecuteMtd (cls=0x0, obj=0x239fe20, 
>> mtd=0x23cd500, signature=0xe26c698 "|\b\002¦¿Áÿø\220\001", plhs=0xa, 
>> args=0x17f79c8, string_to_char=144593636) at javaexec.c:1722
>> #22 0x017e13ec in ojCallJavaMethod (java_method=0xe006dd0, 
>> java_class=0x888aa8, java_data=0x196d530, nlhs=237422232, 
>> plhs=0x6c370418, nrhs=0, prhs=0x23cd500) at javaopaq.c:2916
>> #23 0x017e32fc in ojCallMethod (method_array=0xdd818f0, pmat=0x0, 
>> nlhs=1, plhs=0xbfff95b8, nrhs=0, prhs=0x9f1a8c) at javaopaq.c:4956
>> #24 0x024aa790 in inCallOpaqueMethod (nlhs=1, plhs=0xbfff95b8, 
>> nrhs=1, prhs=0x9f1a88, fcn_ptr=0x87f118) at 
>> mi_interpreter/opaqarr.c:1817
>> #25 0x024aaa9c in inExecOpaqueFcn (nlhs=1, nrhs=1, prhs=0x9f1a88, 
>> fcn_ptr=0x87f118) at mi_interpreter/opaqarr.c:1971
>> #26 0x024f9030 in inExecFunction (nlhs=232265968, nrhs=0, prhs=0x0, 
>> fcn_ptr=0xe26c698) at mi_util/function.c:2359
>> #27 0x024b67b0 in inOpaqueReferenceFcn (name=0x4 <Address 0x4 out of 
>> bounds>, narg=1, args=0xbfff9888) at mi_interpreter/struc.c:2116
>> #28 0x024b84b8 in inDotReference (fieldname=0xde2fa78 "GetOutput") at 
>> mi_interpreter/struc.c:3134
>> #29 0x0248b8e8 in inInterp (dbcheck=3221194816, local_lineno=20, 
>> retdisp=1159, entry_nest=0x2391cc0) at > 
>> mi_interpreter/exinterp.cpp:6126
>> #30 0x0248c1ec in inInterPcode (dbcheck=DEBUGCHECK) at 
>> mi_interpreter/exinterp.cpp:6609
>> #31 0x024bdb48 in inWord (nlhs=0, plhs=<incomplete type>, nrhs=0, 
>> prhs=<incomplete type>, pwd=0xe046008, new_workspace=2) at 
>> mi_interpreter/wordsj.cpp:1271
>> #32 0x024be1f0 in inWordsj (nout=0, outputlst=<incomplete type>, 
>> nin=0, inputlst=<incomplete type>, pwd=0xe046008) at 
>> mi_interpreter/wordsj.cpp:1583
>> #33 0x0249d708 in inRunMP (nlhs=0, plhs=<incomplete type>, nrhs=0, 
>> prhs=<incomplete type>, pwd=0xe046008, from_feval=false) at 
>> mi_interpreter/isword.cpp:4469
>> #34 0x0249d944 in inExecMFile (nlhs=0, nrhs=0, prhs=<incomplete 
>> type>, fcn_ptr=0xe046008) at mi_interpreter/isword.cpp:4620
>> #35 0x024f9030 in inExecFunction (nlhs=232265968, nrhs=0, prhs=0x0, 
>> fcn_ptr=0xe26c698) at mi_util/function.c:2359
>> #36 0x024a8d90 in inMMexExecute (fcn=534, name=0xe00652c "vtktest", 
>> nlhs=0, nrhs=0) at mi_interpreter/oops.c:1418
>> #37 0x0248c55c in inMMex (name=0xe00652c "vtktest", fcn=534, 
>> nlhs=39043196, nrhs=0, local_lineno=0xbfffb5dc, ipaddr=0xe006520) at 
>> mi_interpreter/exinterp.cpp:6792
>> #38 0x0248b3d4 in inInterp (dbcheck=DEBUGCHECKNOEND, local_lineno=0, 
>> retdisp=0, entry_nest=0x192ec40) at mi_interpreter/exinterp.cpp:5956
>> #39 0x0248c1ec in inInterPcode (dbcheck=DEBUGCHECKNOEND) at 
>> mi_interpreter/exinterp.cpp:6609
>> #40 0x02484280 in in_local_call_eval_function (lret=<incomplete 
>> type>, mintf=0x0, pcheader=0xbfffc31c, nlhs=<incomplete type>, 
>> plhs=<incomplete type>, dbcheck=DEBUGCHECKNOEND) at 
>> mi_interpreter/evalstr.cpp:893
>> #41 0x02484d2c in inEvalStringWithIsVarFcn (string=0xde16d98 
>> "vtktest\n", nchar=232265968, eval_type=STATEMENT, nlhs=0, 
>> plhs=<incomplete type>, dbcheck=DEBUGCHECKNOEND, pch=0x0, 
>> lret=<incomplete type>, mintf=0x25690c4, IsVarFunction=0x2484478 
>> <in_is_ws_variable(_m_parser_interface *, char const *)>, 
>> IsVarContext=0x25690c4) at mi_interpreter/evalstr.cpp:1302
>> #42 0x02484dc8 in inEvalString (string=0xdd818f0 "", nchar=0, 
>> eval_type=STATEMENT, nlhs=237422232, plhs=<incomplete type>, 
>> dbcheck=2726499552, pch=0x0, lret=<incomplete type>, mintf=0x25690c4) 
>> at mi_interpreter/evalstr.cpp:1339
>> #43 0x02484e6c in inEvalCmdWithLocalReturnandtype (str=0xde16d98 
>> "vtktest\n", lret=<incomplete type>, dbcheck=DEBUGCHECKNOEND) at 
>> mi_interpreter/evalstr.cpp:1371
>> #44 0x00010a4c in mnParser () at parser.cpp:652
>> #45 0x00002d60 in main (argc=2, argv=0x8a1cdc) at matlab_unix.cpp:658
>> #46 0x000022d0 in _start ()
>> #47 0x00002100 in start ()
>> (gdb)
>
>
> _______________________________________________
> This is the private VTK discussion list. Please keep messages 
> on-topic. Check the FAQ at: <http://public.kitware.com/cgi-bin/vtkfaq>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtkusers
>
>

-- 
Jeff Lee
Software Engineer
Computational Dynamics North America Ltd
21 Lafayette Street, Suite 230
Lebanon NH 03766 USA
fax:   603 643 9994
phone: 603 643 9993 x109
http://www.cd-adapco.com





More information about the vtkusers mailing list