PDA

View Full Version : Segmentation fault



SagoO
01-11-2011, 08:17 AM
Anyone face this problem when using vbo?



glGenBuffers(1, &pattern_buffer);
glBindBuffer(GL_ARRAY_BUFFER, pattern_buffer);
glBufferData(GL_ARRAY_BUFFER, 6, pattern, GL_READ_WRITE);


Output:

Segmentation fault

What is that means?

_arts_
01-11-2011, 08:45 AM
Do you use any extension library (like glew), do you load the addresses of these functions by yourself ?

If not, you need.

If yes, maybe more code should be good.

ugluk
01-11-2011, 09:05 AM
This is the classical case all glew users encounter, where you call functions that are unavailable. Try to append ARB to the function names, compile, link and try again, e.g.

glGenBuffersARB instead of glGenBuffers

SagoO
01-11-2011, 09:11 AM
This is the classical case all glew users encounter, where you call functions that are unavailable. Try to append ARB to the function names, compile, link and try again, e.g.

glGenBuffersARB instead of glGenBuffers

I had appended ARB to the function names as below:



glGenBuffersARB(1, &pattern_buffer);
glBindBufferARB(GL_ARRAY_BUFFER_ARB, pattern_buffer);
glBufferDataARB(GL_ARRAY_BUFFER_ARB, 6, pattern, GL_READ_WRITE);


But I still getting the segmentation fault message.

What is tat message means actually?

mobeen
01-11-2011, 09:53 AM
Have u initialized the glew library by calling
glewInit() after initializing glut library? In order to access those functions, you need to use glew or anyother helper library to obtain the func. pointer/s. If u donot do this, the function pointers are null and when u get try to call a null func. pointer u get the segmentation fault.
Another issue may be that the data pointer u r passing to the glBufferData does not contain sufficient data.

ugluk
01-11-2011, 01:05 PM
Do this:

compile your app with the -g switch.

gdb ./your_app_name_here
r
<wait for your app to crash>
bt

SagoO
01-11-2011, 05:24 PM
Have u initialized the glew library by calling
glewInit() after initializing glut library? In order to access those functions, you need to use glew or anyother helper library to obtain the func. pointer/s. If u donot do this, the function pointers are null and when u get try to call a null func. pointer u get the segmentation fault.
Another issue may be that the data pointer u r passing to the glBufferData does not contain sufficient data.

Even I already initialized the glew library still have the same problem. What do u mean sufficient data?I declare and initialize a 6 bytes vertex array. The size I use is 6 bytes also.

SagoO
01-11-2011, 05:29 PM
Do this:

compile your app with the -g switch.

gdb ./your_app_name_here
r
<wait for your app to crash>
bt

What is that? Can explain further?

I got this:


Reading symbols from /media/Data/My Document/FYP/Implementation/testing...done.
(gdb) r
Starting program: /media/Data/My Document/FYP/Implementation/testing
[Thread debugging using libthread_db enabled]
Virus pattern: trojan

Program received signal SIGSEGV, Segmentation fault.
0x0018f336 in glGetString () from /usr/lib/mesa/libGL.so.1

Rosario Leonardi
01-11-2011, 05:57 PM
Segmentation fault: the memory is subdivided in pages, if you write/read outside from the pages assigned to your program you got this error. This avoid your program to destroy other program.
This usually append when you are using a not initialized pointer.
For example:


class A{
void method();
};
void main()
{
A* pObj;
pObj->method(); // segmentation fault
return 0;
}
Compiling with -g you attach the debug symbol to your program. With debug symbol a debugger like gdb can associate any assembly instruction to high level instruction and you can follow your program step by step, or in case of error it can tell you with function cause the error. Read the manual for gdb, it's a vital tool for every developer.
In your case, gdb it's telling you that the function glGetString is the problem. Are you calling glGetString with a valid and active context?

SagoO
01-11-2011, 10:49 PM
Segmentation fault: the memory is subdivided in pages, if you write/read outside from the pages assigned to your program you got this error. This avoid your program to destroy other program.
This usually append when you are using a not initialized pointer.
For example:


class A{
void method();
};
void main()
{
A* pObj;
pObj->method(); // segmentation fault
return 0;
}
Compiling with -g you attach the debug symbol to your program. With debug symbol a debugger like gdb can associate any assembly instruction to high level instruction and you can follow your program step by step, or in case of error it can tell you with function cause the error. Read the manual for gdb, it's a vital tool for every developer.
In your case, gdb it's telling you that the function glGetString is the problem. Are you calling glGetString with a valid and active context?

But I do not call glGetString function. Why it will cause this problem?Is it possible that other function I had called may invoke this function in the background?

mobeen
01-11-2011, 10:55 PM
Could u post your whole code?

mhagain
01-12-2011, 02:40 AM
What hardware have you? There is a possibility that you're trying to use VBOs on hardware that doesn't support them.

ugluk
01-12-2011, 03:47 AM
No no, we already established he has hw support for VBOs. He's just doing something wrong. Do this SagO:

export LIBGL_SOFTWARE_RENDERING=1
./your_app_name_here

if it crashes, you've made a mistake somewhere, because with sw rendering every card is good enough.

Anyway, SagO, Linux generally does not screw you up so bad as Windows, the crashes are generally less mysterious than in Windows, gdb has never let me down yet. You also have the option of installing a more user-friendly ddd, cgdb, kdbg ... debugger.

Rosario Leonardi
01-12-2011, 04:02 AM
Relaunch gdb with the same parameter and recreate the crash. Then write the command
backtrace
or simply ba
you will get a list with the sequence of function that cause the error. Probably is glewInit that it's calling glGetString to check the extension.
Are you sure that you are calling glewInit when the context is active?

_arts_
01-12-2011, 05:04 AM
Is it possible that other function I had called may invoke this function in the background?

Normally no, maybe glew does it... But it is possible that other calls make effects on other functions, thus ending with segfault here.

What about the pointer glGenBuffers, or glGenBuffersARB, are they not null ?

SagoO
01-12-2011, 06:26 AM
Relaunch gdb with the same parameter and recreate the crash. Then write the command
backtrace
or simply ba
you will get a list with the sequence of function that cause the error. Probably is glewInit that it's calling glGetString to check the extension.
Are you sure that you are calling glewInit when the context is active?

I debug my source code again. Absolutely is the glewInit function cause that as the debugger stop at there. What do u means context is active? Sorry about that I am new to openGL.

SagoO
01-12-2011, 06:43 AM
Is it possible that other function I had called may invoke this function in the background?

Normally no, maybe glew does it... But it is possible that other calls make effects on other functions, thus ending with segfault here.

What about the pointer glGenBuffers, or glGenBuffersARB, are they not null ?



glewInit();
glGenBuffersARB(1, &amp;pattern_buffer);
glBindBufferARB(GL_ARRAY_BUFFER_ARB, pattern_buffer);
glBufferDataARB(GL_ARRAY_BUFFER_ARB, sizeof(pattern), pattern, GL_READ_WRITE_ARB);


I put pointer there. Not null

SagoO
01-12-2011, 06:48 AM
No no, we already established he has hw support for VBOs. He's just doing something wrong. Do this SagO:

export LIBGL_SOFTWARE_RENDERING=1
./your_app_name_here

if it crashes, you've made a mistake somewhere, because with sw rendering every card is good enough.

Anyway, SagO, Linux generally does not screw you up so bad as Windows, the crashes are generally less mysterious than in Windows, gdb has never let me down yet. You also have the option of installing a more user-friendly ddd, cgdb, kdbg ... debugger.

Yup...It still pop out segmentation fault. Is this means crash? I am new to linux and openGL. So, make me hard to learn openGL. I still feel very confuse even I had read many tutorials and tried some of the examples. :confused:

mobeen
01-12-2011, 07:41 AM
Hi,
Could u please post where ur call glutInit from the main func. because I suspect u r calling glewInit before glutInit. Are you sure that glewInit is called after glutInit?

SagoO
01-12-2011, 08:00 AM
Hi,
Could u please post where ur call glutInit from the main func. because I suspect u r calling glewInit before glutInit. Are you sure that glewInit is called after glutInit?

I dint use glutInt...Refer to the previous post..I got post the glewInit code ade...

SagoO
01-12-2011, 08:06 AM
I understand what you means already...Because my code was combine of CPU and GPU process.I use int main() initially. I thought no ned to initialize glut even though I want to use GPU to process. Here is the changes:



void glutInit(int *argcp, char **argv){
glewInit();
glGenBuffersARB(1, &amp;pattern_buffer);
glBindBufferARB(GL_ARRAY_BUFFER_ARB, pattern_buffer);
glBufferDataARB(GL_ARRAY_BUFFER_ARB, sizeof(pattern), pattern, GL_READ_WRITE_ARB);
}


I add glutInit inside the main(). No more segmentation fault error message. Is this correct? If it is I am going to continue the next part.

ugluk
01-12-2011, 08:16 AM
Since you didn't init glut, you've had no context when glew initialized, hence the crash.

While you move to the next part, try to delete the ARB suffixes and compile again and see if your app still works (it is better to leave them, for Windows compiles, I'm just suggesting an experiment, it should work).

mobeen
01-12-2011, 08:18 AM
No this is wrong.
Usually its like this.


void main(int argc, char** argv) {
glutInit(&amp;argc, argv);
glutInitWindowSize(800, 600);
glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGBA | GLUT_DEPTH);
glutCreateWindow("Some title here");

GLenum err = glewInit();
if (GLEW_OK != err)
{
fprintf(stderr, "Error: %s\n", glewGetErrorString(err));
exit(EXIT_FAILURE);
}

... rest of stuff like attaching callbacks and setup stuff for opengl.

glutMainLoop();
}


NOTE: I told u earlier but u never heeded to it (see the first page of this thread


Have u initialized the glew library by calling
glewInit() after initializing glut library?

SagoO
01-12-2011, 08:44 AM
Since you didn't init glut, you've had no context when glew initialized, hence the crash.

While you move to the next part, try to delete the ARB suffixes and compile again and see if your app still works (it is better to leave them, for Windows compiles, I'm just suggesting an experiment, it should work).


What is that ARB suffixes for actually?I compile using linux not windows.



NOTE: I told u earlier but u never heeded to it (see the first page of this thread
Quote:

Have u initialized the glew library by calling
glewInit() after initializing glut library?



Lol...Sorry about that...I miss that part. But very strange..If i follow your code, the problem happens again. I am not going to create a new window for display the drawing. As what I am trying to do is simple calculation. But not drawing.

mhagain
01-12-2011, 09:10 AM
You need a window to have an OpenGL context. There are tricks you can do (like creating a hidden window) but GLUT isn't going to be flexible enough. It's easier to just create a Window.

The -ARB suffixes were used by earlier versions of OpenGL where VBOs were an extension rather than part of the core. The reason why you'd use them is if you need compatibility with older hardware (no, Windows doesn't need them and can use the versions of the functions without them so long as the driver exports the entry points; this is nothing to do with Windows, it's the driver). Otherwise you don't need to use them.

SagoO
01-12-2011, 09:12 AM
I suddenly found that I need to create a window to check my result. By the way, I follow exactly your code. Why the terminal just like waiting for something but no display comes out?



glutInit(&amp;argc, argv);
glutInitWindowSize(800, 600);
glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGBA | GLUT_DEPTH);
glutCreateWindow("GPU display");

GLenum err = glewInit();
if (GLEW_OK != err)
{
fprintf(stderr, "Error: %s\n", glewGetErrorString(err));
exit(EXIT_FAILURE);
}

glGenBuffersARB(1, &amp;pattern_buffer);
glBindBufferARB(GL_ARRAY_BUFFER_ARB, pattern_buffer);
glBufferDataARB(GL_ARRAY_BUFFER_ARB, sizeof(pattern), pattern, GL_READ_WRITE_ARB);

int *ptr;
ptr = glMapBufferRange(pattern_buffer, pattern[0], 1, GL_MAP_READ_BIT);
printf("Ptr: ",ptr);


Is it necessary that I need glutMainLoop()? I found that if I include this, my program hang there when running. But if not include that, seems like no window pop out also even though the program run smoothly.

ugluk
01-12-2011, 09:33 AM
Where's your rendering function? Anyway, you are all set, go over to NeHe and do some tuts and yes you need to call glutMainLoop(), if you want to render something.

ZbuffeR
01-12-2011, 09:36 AM
You need to glutMainLoop to handle events such as display, resize, input, ...

You can do the initialisation of GL stuff before calling it, as hinted by mobeen.

SagoO
01-12-2011, 09:45 AM
Where's your rendering function? Anyway, you are all set, go over to NeHe and do some tuts and yes you need to call glutMainLoop(), if you want to render something.

Ok...Have to study deeper...Thanks for the help... :D