Re: [Mesa3d-users] 32bit vs 64bit question regarding glLightfv (one works, the other crashes)

[Brian P. <br...@vm...>]

Tobias Burnus wrote:
> Hello,
> 
> I have the problem that calling glLightfv works with the 32bit version
> of mesa but fails with the 64bit version on a x86-64 Linux system:
> 
> $ cat test.c
> #include <GL/gl.h>
> 
> int main ()
> {
>   GLfloat ambient[4]      = {0.2, 0.2, 0.2, 1.0};
>   glLightfv(GL_LIGHT0, GL_AMBIENT,  ambient);
>   return 0;
> }
> 
> $ gcc test.c -lGL && ./a.out
> Segmentation fault
> $ gcc -m32 test.c -lGL && ./a.out
> $
> 
> (Reduced example from http://www.xcrysden.org/.) I failed to see what
> goes wrong here as the syntax looks fine, but I also find it unlikely
> that it fails both with an old Fedora 6 with
> mesa-libGL-devel-6.5.1-9.fc6 and on an openSUSE Factory with
> Mesa-7.7-5.3.x86_64, which somehow implies a user error instead of a
> library problem.
> 
>  * * *
> 
> For completeness, if I use glutInit(); ....; glutCreateWindow(...)
> before calling glLightfv(), it does not crash with mesa-64bit. Xcrysden
> is to convoluted for me to really see what is called where. Is there
> anything which I should tell the Xcryden developers to handle differently?

The "problem" with your example above is there's no rendering context 
bound when glLightfv() is called.  We're probably trying to jump 
through a null pointer in the dispatcher.

I guess Xcryden is making some GL calls w/out a bound rendering 
context.  That's usually an application bug.

As far as Mesa goes, my guess is we've got something wrong in the 
x86-64 API dispatch code.  I'm not too knowledgable of x86-64 assembly 
code.  Have you filed a bug report about this?

-Brian