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
|
