Bug 4270

Summary: Mesa 6.2.1 implementation error: bad color table type in set_component_sizes 0x0
Product: Mesa Reporter: Thomas Kohler <kohler>
Component: Mesa coreAssignee: mesa-dev
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: high    
Version: 6.2.1   
Hardware: Alpha   
OS: other   
Whiteboard:
i915 platform: i915 features:

Description Thomas Kohler 2005-08-27 09:01:35 UTC
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
Comment 1 Brian Paul 2005-08-28 10:16:31 UTC
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().
Comment 2 Thomas Kohler 2005-08-29 06:18:55 UTC
(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
Comment 3 Brian Paul 2005-08-29 07:44:49 UTC
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.