Hi,
   I recently compiled povray 3.5c  (Unix: gcc@alphaev56-dec-osf5.1) -
that is HP(Compaq) Tru64 v5.1b and it runs for the most part just fine.
However it crashes when it starts *parsing* meshes !


Parsing...Floating exception


// Here is an example to illustrate it:

camera {
 location  <0,0,-10>
 look_at   <0,0,0>
 right x * 1.0
}

background { color rgb <1,1,0> }

light_source {
 < 0.000, 2.000, -5.000 >
 color rgb <1.000, 1.000, 1.000 >
}

sphere { <0,0,0>, 0.3
  texture { pigment { color rgb z }
            finish  { ambient 0.2 diffuse 0.7 specular 0.3 }
          }
}

#declare xxT1 = texture {
            pigment { color rgb x }
            finish  { ambient 0.2 diffuse 0.7 specular 0.3 }
          }

mesh {
  triangle {
    <-1, -1, 0>, <1,-1,0>, <0,0,0>
    texture { xxT1 }
  }
}
// end of the example.

I ran dbx :
Parsing...signal Floating point exception at
[_Z12Mesh_Hash_UVPiS_PPA2_dPd:6
+0x32dc,0x1200901cc] *  This module was written by Dieter Bayer [DB]

When I type in a couple of conts it eventually gets through and renders
a correct image !
Does anyone know what might be wrong ?
Again this is only on Compaq Alpha Tru64 ( 600au and ES40 ). This thing
runs fine on Irix and Linux.
Ah, gcc version : gcc (GCC) 3.2.3

Thanks,

   Lothar

Post a reply to this message

In article <3EAB0698.AA29884A@helix.nih.gov> , Lothar Esser 
<les### [at] helixnihgov>  wrote:

> Does anyone know what might be wrong ?

A bug in the compiler?  Turn off all optimsations to see what iis wrong.
And also lok at the generated code if it still crashes.

    Thorsten

Post a reply to this message

Lothar Esser wrote:
> I ran dbx :
> Parsing...signal Floating point exception at
> [_Z12Mesh_Hash_UVPiS_PPA2_dPd:6
> +0x32dc,0x1200901cc] *  This module was written by Dieter Bayer [DB]
> 
Please compile with debugging symbols and find out in which source 
code line (inside Mesh_Hash_UV, mesh.cpp) the SIGFPE is triggered. 

Wolfgang

Post a reply to this message

Wolfgang Wieser wrote:

> Lothar Esser wrote:
> > I ran dbx :
> > Parsing...signal Floating point exception at
> > [_Z12Mesh_Hash_UVPiS_PPA2_dPd:6
> > +0x32dc,0x1200901cc] *  This module was written by Dieter Bayer [DB]
> >
> Please compile with debugging symbols and find out in which source
> code line (inside Mesh_Hash_UV, mesh.cpp) the SIGFPE is triggered.
>

Sorry it took me a while. I kind of suspected that it is a gcc problem so
I decided to spend some time to recompile gcc 3.2.3 and see whether I see
a problem there. I did not. Here is the output from gdb
$gdb ./povray
{ here comes the usual header from povray, no problem there}
  Statistics Stream to console....On
  Warning Stream to console.......On
Parsing...
Program received signal SIGFPE, Arithmetic exception
0x00000001200c9b28 in Mesh_Hash_UV(int*, int*, double (**) [2], double*)
(Number=0x11fffb9b4, Max=0x11fffb9c8, Elements=0x11fffbb50,
    aPoint=0x11fffbb08) at mesh.cpp:1972
1972      hash = (unsigned)((int)(326.0*P[U])^(int)(694.7*P[V])) %
HASH_SIZE;
(gdb) where
#0  0x00000001200c9b28 in Mesh_Hash_UV(int*, int*, double (**) [2],
double*) (Number=0x11fffb9b4, Max=0x11fffb9c8, Elements=0x11fffbb50,
aPoint=0x11fffbb08) at mesh.cpp:1972
#1  0x00000001200e1ed8 in Parse_Mesh() () at parse.cpp:3320
#2  0x00000001200e9258 in Parse_Object() () at parse.cpp:5832
#3  0x00000001200e9fa0 in Parse_Frame() () at parse.cpp:6180
#4  0x00000001200d9090 in Parse() () at parse.cpp:293
#5  0x00000001201381c8 in FrameRender() () at povray.cpp:876
#6  0x0000000120137f88 in FrameLoop() () at povray.cpp:786
#7  0x0000000120137c14 in povray_render(int, char**) (argc=2,
argv=0x1400d4420) at povray.cpp:497
#8  0x00000001201376f8 in main (argc=2, argv=0x11fffc018) at
povray.cpp:286
(gdb) list
286         ret = povray_render(argc, argv);
287        #endif
289        /* Finish */
290        povray_terminate();
292        return ret;
293     }
294     #endif
(gdb)


-- I am not terribly good at debugging. Does anyone have an idea what to try next?

(again I use gcc 3.2.3 on alphaev68 (this time, same problem with ev56) )

Thanks for any pointers ...

Lothar

Post a reply to this message

Lothar Esser wrote:

>
> 0x00000001200c9b28 in Mesh_Hash_UV(int*, int*, double (**) [2], double*)
> (Number=0x11fffb9b4, Max=0x11fffb9c8, Elements=0x11fffbb50,
>     aPoint=0x11fffbb08) at mesh.cpp:1972
> 1972      hash = (unsigned)((int)(326.0*P[U])^(int)(694.7*P[V])) %
> HASH_SIZE;
> (gdb) where
> #0  0x00000001200c9b28 in Mesh_Hash_UV(int*, int*, double (**) [2],
> double*) (Number=0x11fffb9b4, Max=0x11fffb9c8, Elements=0x11fffbb50,
> aPoint=0x11fffbb08) at mesh.cpp:1972
>

What I found out in the meantime is that apparently absurdly small values are passed
on to Mesh_Hash_UV in form of UV_VECT aPoint. That is

aPoint[U] = 1.0e-311 ; aPoint[V] = 1.0e-322;
The following recasting to int or even multiplication with another double leads to a
SIGFPE. I suspect that somehow these numbers are too small. So I allowed myself to
do:
P[U] = rint(P[U]); P[V] = rint(P[V]); after the Assign_UV_Vect(P, aPoint) statement
and then it worked.
Is this a unique problem of Tru64 or is there a switch or directive that takes care
of numerical underflow issues like these ?
( Ah, the puzzle somehow is now, why is aPoint so small ... this I have no clue about
- something uninitialized maybe ?)

Thanks for any information.

Lothar

Post a reply to this message

More precisely the values passed on to

Mesh_Hash_UV

are FP_POS_DNORM which probably points to some uninitialized variable problem.
Unfortunately I cannot track that down.
So instead of rounding to the nearest integer, I check the fp_class and when it is
DNORM then I arbitrarily set it to 0.0;
if ( fp_class(P[U])  < 8 ) P[U] = 0.0; if ( fp_class(P[V])  < 8 ) P[V] = 0.0;
This works perfectly so far.

Any other ideas ?

Lothar

Post a reply to this message