Segmentation fault using glDisable... - comp.graphics.api.opengl

Hi all! I have a very big problem. I'm using openGL in an application, and everything went fine. But today suddently I get a segmentation fault when the application calls glDisable in setupGL function. It only does some glDisable calls. It worked fine till yesterday! Any idea? Anyone experienced the same problem? Thanks in advance! PS: i'm using Mandriva 2006 with mesa and glut installed.

On 2006-03-15, Paolo <paomic@gmail.com> wrote: > Hi all! I have a very big problem. I'm using openGL in an application, > and everything went fine. But today suddently I get a segmentation > fault when the application calls glDisable in setupGL function. It only > does some glDisable calls. It worked fine till yesterday! > > Any idea? Anyone experienced the same problem? Not without giving us some more info. The problem is certainly with your program, mesa works fine. Reduce your code to a minimal compilable program that exhibits the problem and post it (if you do not find your bug in the process of doing so). -- John Tsiombikas (Nuclear / Mindlapse) nuclear@siggraph.org http://nuclear.demoscene.gr/

Well I'm not doing anything special. I need to open a windows and display a video. Before opening the window I call setupGL that initializes the gl library using GLdisable. I found this code on the net, it has a comment saying "disabling function that may slow down.." ecc. or something like that... If I comment this function everything works fine...

Paolo wrote: > Well I'm not doing anything special. I need to open a windows > and display a video. Before opening the window I call setupGL > that... You must use OpenGL commands _after_ a window and a rendering context has been created. Wolfgang Draxinger --

Yes, I used it after initializing OpenGL and everything... Could it be a driver problem? I don't think it's a program fault, since on another computer it works well and I didn't change anything in this source file!

I was looking ot the output of the application and I found out this: if I uncomment the setupGL function, I get the segmfault and this error: 0xb6f62e09 in glGetString () from /usr/X11R6/lib/libGL.so.1 but if I comment it, it seems to load a different library: Loading required GL library /usr/lib/libGL.so.1 I think it's the problem right? Is it normal I have two copies of the same library?

Paolo wrote: > Yes, I used it after initializing OpenGL and everything... > Could it be a driver problem? I don't think it's a program > fault, since on another computer it works well and I didn't > change anything in this source file! Which OS, which HW and driver. I got some issues with some GLX functions: Using nVidia it worked fine but on ATI it didn't. Then I adopted the sources for ATI, but it crashed then on nVidia. Finally I found out, that GLEW was the reason for that behaviour, namely the GLX extensions it loads. Since then I don't use GLEW for GLX extension stuff. Wolfgang Draxinger --

Paolo wrote: > I think it's the problem right? Is it normal I have two copies > of the same library? Probably. I think the setupGL function tries to manually load the OpenGL libaray using dlopen and uses the old and depreciated location. Or setupGL is implemented in an external lib, that was compiled and linked against an libGL in /usr/X11R6/lib. Normally all libraries should now be in /usr/lib I think, that the library in /usr/X11R6/lib is Mesa3D, while the one in /usr/lib/ is the one deployed with your graphics card's drivers. Wolfgang Draxinger --

I'm using Mandriva on a Acer notebbok. I have ATI RADEON X300. I just ninstalled the drivers, but nothing changed. What do you mean by "adopted the sources for ATI"? Waht did you modify? I don't know what GLEW is...

> I think, that the library in /usr/X11R6/lib is Mesa3D, while the > one in /usr/lib/ is the one deployed with your graphics card's > drivers. Do you know a way to check it exactly? So mesa3D is someway buggy? Should I remove it?

On 2006-03-16, Paolo <paomic@gmail.com> wrote: > > Yes, I used it after initializing OpenGL and everything... Could it be > a driver problem? I don't think it's a program fault, since on another > computer it works well and I didn't change anything in this source file! I will say it again, post a minimal comilable program that exhibits the problematic behaviour so we can test it and se what's wrong. Otherwise chances are that you will not recieve any meaningful feadback. And please take the time to make the program as *minimal* as possible. -- John Tsiombikas (Nuclear / Mindlapse) nuclear@siggraph.org http://nuclear.demoscene.gr/

Here's where i get the segmentation fault: static void setupGL(void) { // Disable stuff that's likely to slow down glDrawPixels. // (Omit as much of this as possible, when you know in advance // that the OpenGL state will already be set correctly.) glDisable(GL_ALPHA_TEST); glDisable(GL_BLEND); glDisable(GL_DEPTH_TEST); glDisable(GL_DITHER); glDisable(GL_FOG); glDisable(GL_LIGHTING); glDisable(GL_LOGIC_OP); glDisable(GL_STENCIL_TEST); glDisable(GL_TEXTURE_1D); glDisable(GL_TEXTURE_2D); glPixelTransferi(GL_MAP_COLOR, GL_FALSE); glPixelTransferi(GL_MAP_STENCIL, GL_FALSE); glPixelTransferi(GL_RED_SCALE, 1); glPixelTransferi(GL_RED_BIAS, 0); glPixelTransferi(GL_GREEN_SCALE, 1); glPixelTransferi(GL_GREEN_BIAS, 0); glPixelTransferi(GL_BLUE_SCALE, 1); glPixelTransferi(GL_BLUE_BIAS, 0); glPixelTransferi(GL_ALPHA_SCALE, 1); glPixelTransferi(GL_ALPHA_BIAS, 0); glPixelStorei(GL_PACK_ALIGNMENT, 8); glPixelStorei(GL_UNPACK_ALIGNMENT, 8); // Disable extensions that could slow down glDrawPixels. const GLubyte* extString = glGetString(GL_EXTENSIONS); if (extString != NULL) { if (strstr((char*) extString, "GL_EXT_convolution") != NULL) { glDisable(GL_CONVOLUTION_1D_EXT); glDisable(GL_CONVOLUTION_2D_EXT); glDisable(GL_SEPARABLE_2D_EXT); } if (strstr((char*) extString, "GL_EXT_histogram") != NULL) { glDisable(GL_HISTOGRAM_EXT); glDisable(GL_MINMAX_EXT); } if (strstr((char*) extString, "GL_EXT_texture3D") != NULL) { glDisable(GL_TEXTURE_3D_EXT); } } } IF I comment a line with glDisable, i get the same error in the next one. John Tsiombikas (Nuclear / Mindlapse) ha scritto: > On 2006-03-16, Paolo <paomic@gmail.com> wrote: > > > > Yes, I used it after initializing OpenGL and everything... Could it be > > a driver problem? I don't think it's a program fault, since on another > > computer it works well and I didn't change anything in this source file! > > I will say it again, post a minimal comilable program that exhibits the > problematic behaviour so we can test it and se what's wrong. Otherwise > chances are that you will not recieve any meaningful feadback. > And please take the time to make the program as *minimal* as possible. > > -- > John Tsiombikas (Nuclear / Mindlapse) > nuclear@siggraph.org > http://nuclear.demoscene.gr/

Paolo wrote: >> I think, that the library in /usr/X11R6/lib is Mesa3D, while >> the one in /usr/lib/ is the one deployed with your graphics >> card's drivers. > > Do you know a way to check it exactly? So mesa3D is someway > buggy? Should I remove it? No Mesa3D is not buggy, but those are probably two completely different libs, that are interfering. The glDisable call probably goes everywhere, but not where it should go. Wolfgang Draxinger --

Paolo wrote: > How can I see if this is the problem I have? Well, it uses 2 different libraries, so you have this problem. I'd suggest to recompile the library that contains the setupGL function, so that it uses the /usr/lib/libGL.so > How can I update the glut and Mesa library? You don't need to update GLUT, and you have to get rid of MesaGL or make sure that it doesn't get linked by your Program. You only need the Mesa3D library if you got no driver 3D support for your hardware. > I have libglut.so.3.7 but I know > there are newer ones... Maybe I can try to get those ones... You don't have a version problem, you have a library concurency problem. Wolfgang Draxinger --

On Thu, 16 Mar 2006 02:29:24 -0800, Paolo wrote: > 0xb6f62e09 in glGetString () from /usr/X11R6/lib/libGL.so.1 > > > Loading required GL library /usr/lib/libGL.so.1 > > I think it's the problem right? Is it normal I have two copies of the > same library? On my system (Gentoo), /usr/X11R6 is a symlink to /usr, so both libraries are the same.