I'm still trying to port Java3D to OpenVMS with Mesa 6.2.1 as OpenGL implementation. When the Canvas3D should be displayed on the screen the program crashes. Shortly before crashing I get this Mesa implementation error. Unfortunately I was not able to debug the shared libraries, because when the debugger is running, Java can not lock the drawingSurface and is stuck (maybe problem with threads??). So I can't get to the problem code with the Debugger. I try now to follow the path with printout messages, but I do not understand very much about the drawing mechanisms. So maybe this implementation error is not even related to the segfault I get. Concerning the implementation error, I think that the _mesa_ColorTable is called with the wrong target (GL_PROXY_TEXTURE_COLOR_TABLE_SGI), but again I have no idea, where the _mesa_ColorTable is called and why it is called with that target. Some light into this dark area of porting java3d to OpenVMS is very appreciated. Please find below the output messages and the segfault I get. best, Thomas CUSTER> java "JavaVizObj" Unknown host: WSA200 Java 3D [dev] 1.3.3-pre1-0508221737-experimental 22 Aug 2005 17:37:05 CEST Initializing Java 3D runtime system: version = 1.3.3-pre1-0508221737-experimental 22 Aug 2005 17:37:05 CEST vendor = Sun Microsystems, Inc. specification.version = 1.3 specification.vendor = Sun Microsystems, Inc. Java 3D system initialized graphics library = UNKNOWN NativeConfigTemplate3D: using device X11GraphicsDevice[screen=0] display 57026592 screen 0 configuration count: 10 visual id at index 0: 39 visual id at index 1: 40 visual id at index 2: 41 visual id at index 3: 42 visual id at index 4: 33 visual id at index 5: 34 visual id at index 6: 35 visual id at index 7: 36 visual id at index 8: 37 visual id at index 9: 38 display 0x3662820, fbConfigList 0x36650f8, fbConfig 0x33a14f0, fbConfigId 39 ********* VisualID = 39 chooseOglVisual() returns 39 pointer to GLXFBConfig is 57037048 VirtualUniverse created. Locale created. ViewBranch created. ContentBranch created. display the JFrame with my Canvas3D... getDrawingSurfaceInfo: lock=14 Canvas3D_createNewContext: fbConfigListPtr 0x36650f8 fbConfigList 0x36650f8, fbConfigList[0] 0x33a14f0 Canvas3D_getPropertiesFromCurrentContext: pixelFormat: 0 Canvas3D_getPropertiesFromCurrentContext: glVersion: 1.5 Mesa 6.2.1 Canvas3D_getPropertiesFromCurrentContext: glVendor: Brian Paul Canvas3D_getPropertiesFromCurrentContext: glRenderer: Mesa X11 Canvas3D_extractVersionInfo: majorNumStr = 1, minNumStr = 5 _mesa_ColorTable(...): printing arguments... _mesa_ColorTable(...): target=0x80bd _mesa_ColorTable(...): internalFormat=0x1908 _mesa_ColorTable(...): width=256 _mesa_ColorTable(...): format=0x1907 _mesa_ColorTable(...): type=0x1404 _mesa_ColorTable(...): case GL_PROXY_TEXTURE_COLOR_TABLE_SGI: (target 0x80bd) _mesa_ColorTable(...): table->Type=0x0 _mesa_ColorTable(...): proxy=1 _mesa_ColorTable(...): before calling set_component_sizes(table) _mesa_ColorTable(...): table->Size=256 _mesa_ColorTable(...): table->IntFormat=0x1908 _mesa_ColorTable(...): table->Format=0x1908 _mesa_ColorTable(...): table->Type=0x0 Mesa 6.2.1 implementation error: bad color table type in set_component_sizes 0x0 Please report at bugzilla.freedesktop.org Canvas3D_disableFog: glDisable(GL_FOG) Canvas3D_setRenderMode: glDrawBuffer(GL_BACK) Canvas3D_textureclear(): Canvas3D_setRenderMode: glDrawBuffer(GL_BACK) %SYSTEM-F-HPARITH, high performance arithmetic trap, Imask=00000000, Fmask=00000 001, summary=08, PC=0000000002EC5F98, PS=0000001B -SYSTEM-F-FLTOVF, arithmetic trap, floating overflow at PC=0000000002EC5F98, PS= 0000001B %TRACE-F-TRACEBACK, symbolic stack dump follows image module routine line rel PC abs PC libMesaGL M_MATRIX _math_transposefd 25977 0000000000002DE8 0000000002EC5F98 libMesaGL MATRIX _mesa_LoadTransposeMatrixdARB 44823 0000000000001394 0000000002ED6364 libMesaGL DISPATCH glLoadTransposeMatrixdARB 36766 000000000000CAD4 0000000002E2D764 j3dcore-ogl ATTRIBUTES Java_javax_media_j3d_Canvas3D_setProjectionMatrix 33537 0000000000000974 0000000002D1B3D4 0 00000000401262A4 00000000401262A4 0 00000000400BAD54 00000000400BAD54 0 00000000400A94F4 00000000400A94F4 JAVA$FVM_SHR 0 00000000000C532C 000000000011732C JAVA$FVM_SHR ICALL make_native_call 30217 00000000000009A8 000000000010B008 JAVA$FVM_SHR INTERP interpret 32062 0000000000000168 00000000000BD828 JAVA$FVM_SHR JNI jni_call 34298 000000000000112C 00000000000C387C JAVA$FVM_SHR JNI jni_CallVoidMethodA 34602 0000000000001E10 00000000000C4560 JAVA$FVM_SHR JNI jni_CallVoidMethod 34620 0000000000001E98 00000000000C45E8 JAVA$FVM_SHR THREAD java_thread_start 47454 000000000000123C 00000000000F06EC JAVA$FVM_SHR THREAD thread_body 47322 0000000000000CB4 00000000000F0164 PTHREAD$RTL 0 0000000000055D7C 000000007BD25D7C PTHREAD$RTL 0 0000000000042B90 000000007BD12B90 0 0000000000000000 0000000000000000 PTHREAD$RTL ? ? 0 FFFFFFFF80271ED4 FFFFFFFF80271ED4 %CMA-F-EXIT_THREAD, current thread has been requested to exit
I've fixed the color table problem in CVS. I don't think this is related to the arithmetic exception though. When you get the stack trace, could you print the 16 values in the matrix passed to _mesa_LoadTransposeMatrixdARB()? My guess is one of the double-precision values is outside the range of single precision and we'll have to add appropriate checks in _math_transposed().
(In reply to comment #1) > I've fixed the color table problem in CVS. > > I don't think this is related to the arithmetic exception though. When you get > the stack trace, could you print the 16 values in the matrix passed to > _mesa_LoadTransposeMatrixdARB()? My guess is one of the double-precision values > is outside the range of single precision and we'll have to add appropriate > checks in _math_transposed(). > Thanks, you brought me to onto the right path. When printing the matrix the first value in the matrix was huge (10^100). I then realized that it might me a problem with the different floating point representations on VMS. I used to compile the java3d shared library with /float=IEEE, whereas the default mms files from mesa do not specify any flag, which means that the VAX G_FLOAT type is used. Now it looks like the two different floating point types in the two shared libraries were causing the problems. When recompiling the mesa library with /float=IEEE, then it works perfectly fine. I would suggest to include this compiler flag into the mms files, because IEEE is more standard than the VAX floating point representation. thanks again for your quick help. Thomas
I've added a note about this to the README.VMS file. Closing the bug now.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.