SEGFAULT with OpenGL ES glDrawArrays

Started by
3 comments, last by Geometrian 10 years, 4 months ago
Hi,

I'm trying to draw simple things with OpenGL ES on a Raspberry Pi.

I created a context through the X system and the glx_create_context_es2_profile extension. This resulted in what I hope is an OpenGL ES 2.0 context (the testing functions gave weird values), but it seems to work for some things (e.g., it gave salient feedback on a shader, which it successfully compiled).

The code is:
GLint loc_vert = program->get_location_attribute("vertex");
printf("Loc vert=%d, vertex size=%d\n",loc_vert,sizeof(Vertex));
glEnableVertexAttribArray(loc_vert); glVertexAttribPointer(loc_vert, 4,GL_FLOAT, GL_FALSE, sizeof(Vertex),vertices);

printf("Begin glDrawArrays=%p with %d,%d,%d\n",glDrawArrays, mode,0,num_vertices);
glDrawArrays(mode, 0,num_vertices);
printf("End glDrawArrays=%p\n",glDrawArrays);

glDisableVertexAttribArray(loc_vert);
The "vertices" array is a static array of four vertices

The output is:

Loc vert=0, vertex size=68
Begin glDrawArrays=<some ptr> with 1,0,2
segfault

I checked against the documentation and my previous code, and this should be valid (it also runs fine on two other systems).

I took the liberty of disassembling glDrawArrays:

Dump of assembler code for function glDrawArrays:
0xb6e63500 <+0>: ldr r3, [pc, #42985368] ; 0xb6e63528 <glDrawArrays+40>
0xb6e63504 <+4>: push {r4, lr}
0xb6e63508 <+8>: mov r4, r0
0xb6e6350c <+12>: ldr r3, [pc, r3]
0xb6e63510 <+16>: bl 0xb6e6f110
0xb6e63514 <+20>: ldr r3, [r0, r3]
0xb6e63518 <+24>: mov r0, r4
0xb6e6351c <+28>: ldr r3, [r3, #3122144] ; 0x4d8
0xb6e63520 <+32>: blx r3
0xb6e63524 <+36>: pop {r4, pc}
0xb6e63528 <+40>: andeq r8, r1, r12, asr sp
End of assembler dump.

It segfaults on "0xb6e63510 <+16>", which is a jump.

Ideas?
-G

[size="1"]And a Unix user said rm -rf *.* and all was null and void...|There's no place like 127.0.0.1|The Application "Programmer" has unexpectedly quit. An error of type A.M. has occurred.
[size="2"]

Advertisement
After looking around at a related issue, I found this StackOverflow question. Therefore, I changed the code to:
GLint loc_vert = program->get_location_attribute("vertex");

GLuint vao;
glGenVertexArrays(1,&vao);
glBindVertexArray(vao);

GLuint vbo;
glGenBuffers(1,&vbo);
glBindBuffer(GL_ARRAY_BUFFER,vbo);
glBufferData(GL_ARRAY_BUFFER, num_vertices*sizeof(Vertex),vertices, GL_STATIC_DRAW);

glEnableVertexAttribArray(loc_vert);
glVertexAttribPointer(loc_vert, 4,GL_FLOAT, GL_FALSE, sizeof(Vertex),NULL);

glDrawArrays(mode, 0,num_vertices);

glDisableVertexAttribArray(loc_vert);

glDeleteBuffers(1,&vbo);
glDeleteVertexArrays(1,&vao);
This does not fix the problem.

[size="1"]And a Unix user said rm -rf *.* and all was null and void...|There's no place like 127.0.0.1|The Application "Programmer" has unexpectedly quit. An error of type A.M. has occurred.
[size="2"]

I wasn't able to set up a debug context on the Pi since GLEW 1.10 isn't supported by default and setting it up would be a pain. However, I can check glGetError, which returns 0 right before glDrawArrays(...), as it should.

[size="1"]And a Unix user said rm -rf *.* and all was null and void...|There's no place like 127.0.0.1|The Application "Programmer" has unexpectedly quit. An error of type A.M. has occurred.
[size="2"]

&nbsp;

Hi,

I'm trying to draw simple things with OpenGL ES on a Raspberry Pi.

I created a context through the X system and the glx_create_context_es2_profile extension. This resulted in what I hope is an OpenGL ES 2.0 context (the testing functions gave weird values), but it seems to work for some things (e.g., it gave salient feedback on a shader, which it successfully compiled).


The Raspberry Pi doesn't, currently, support it's hardware OpenGL ES through GLX. You've probably got a Mesa context.

You have to get the GL context using the Broadcom and EGL APIs. Look at the example in /opt/vc/src/hello_pi/hello_triangle2.
That is extremely unfortunate, but it seems to be correct. See also:

The traditional way (on Linux) is to use the X window system to provide a surface on which the OpenGL/OpenGL ES surface can be rendered. At this moment, the implementation of X for the Raspberry Pi is unable to do this, and so you can’t use X to provide your surface. I am very sure that this support will be added in time, but until then, people wanting to play with this will have to connect up the OpenGL ES side of things to the display by another method.


I'll see about setting up a context with those APIs. Thanks,

[size="1"]And a Unix user said rm -rf *.* and all was null and void...|There's no place like 127.0.0.1|The Application "Programmer" has unexpectedly quit. An error of type A.M. has occurred.
[size="2"]

This topic is closed to new replies.

Advertisement