Segmentation fault

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?

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.

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?

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.

Do this:

compile your app with the -g switch.

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

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.

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

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?

Could u post your whole code?

What hardware have you? There is a possibility that you’re trying to use VBOs on hardware that doesn’t support them.

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.

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?

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 ?

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.


glewInit();
glGenBuffersARB(1, &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

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:

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…