Created attachment 92718 [details]
video demonstrating the issue

another issue is that if 

    glGenVertexArrays (1, &vao_id);
    glBindVertexArray (vao_id);

from lines 46-47 are not used and the is drawn with

    glEnableVertexAttribArray (position_id);
    glBindBuffer (GL_ARRAY_BUFFER, vertex_buffer);
    glVertexAttribPointer (position_id, 3, GL_FLOAT, GL_FALSE, 0, nullptr);

    glEnableVertexAttribArray (color_id);
    glBindBuffer (GL_ARRAY_BUFFER, color_buffer);
    glVertexAttribPointer (color_id, 3, GL_FLOAT, GL_FALSE, 0, nullptr);

    glDrawArrays (GL_TRIANGLES, 0, 36);


instead of

another issue is that if there two lines

    glGenVertexArrays (1, &vao_id);
    glBindVertexArray (vao_id);

from lines 46-47 are removed and the cube is drawn with

    glEnableVertexAttribArray (position_id);
    glBindBuffer (GL_ARRAY_BUFFER, vertex_buffer);
    glVertexAttribPointer (position_id, 3, GL_FLOAT, GL_FALSE, 0, nullptr);

    glEnableVertexAttribArray (color_id);
    glBindBuffer (GL_ARRAY_BUFFER, color_buffer);
    glVertexAttribPointer (color_id, 3, GL_FLOAT, GL_FALSE, 0, nullptr);

    glDrawArrays (GL_TRIANGLES, 0, 36);


instead of

    glBindVertexArray (vao_id);
    glDrawArrays (GL_TRIANGLES, 0, 36);

the test case app breaks with a segmentetion fault while using opnegl 3.3 context, however both ways work just fine with the old created context!!

Well, it should be noted, that test case is a OpenGL-cpp.tar.gz file 

and the mentioned above video is a .webm file

This test sample runs fine as well when started with  $ optirun ./tutorial4 
on configure
Vendor: ........... NVIDIA Corporation
Renderer: ......... GeForce GT 640M/PCIe/SSE2
Version: .......... 3.3.0 NVIDIA 331.38
GLSL version: ..... 3.30 NVIDIA via Cg compiler
on GL init
shader id is 2
shader id is 3
on configure

this bug is not fixed in mesa 10.0.3

Vendor: ........... Intel Open Source Technology Center
Renderer: ......... Mesa DRI Intel(R) Ivybridge Mobile 
Version: .......... 3.3 (Core Profile) Mesa 10.0.3
GLSL version: ..... 3.30

I've encountered this segfault before, and i think i can give some useful informations.
As stated in the file src/mesa/main/varray.c:

   /* Page 407 (page 423 of the PDF) of the OpenGL 3.0 spec says:
    *
    *     "Client vertex arrays - all vertex array attribute pointers must
    *     refer to buffer objects (section 2.9.2). The default vertex array
    *     object (the name zero) is also deprecated. Calling
    *     VertexAttribPointer when no buffer object or no vertex array object
    *     is bound will generate an INVALID_OPERATION error..."
    *
    * The check for VBOs is handled below.
    */

That means you must use a VAO to encapsulate these calls to conform the spec.

Of course this is not a good reason to end up with a segmentation fault, especially when everyone around keep not using VAO with recent core profiles... 

So, in order to avoid the crash you can just comment the line 390 in varray.c:

   if (ctx->API == API_OPENGL_CORE
       && (ctx->Array.VAO == ctx->Array.DefaultVAO)) {
      _mesa_error(ctx, GL_INVALID_OPERATION, "%s(no array object bound)",
                  func);
   //   return;
   }

This way the deprecated default VAO "0" will be used, and everything should work. Maybe some testing later in the process should also be implemented...

Just in case you want know: the segfault happens line 112 in src/mesa/drivers/dri/i965/intel_upload.c, when memcpy is call with null src and dest.

Be aware that this workaround is not fully tested, and comes with no warranty.  

For the overlapping triangles problem, i've never seen that before... so maybe it is a problem in your code.

Thank you for the explanation, maybe your are correct. From my point of view it should definitely not end up with a segmentation fault.
(In reply to comment #6)
> I've encountered this segfault before, and i think i can give some useful
> informations.
...  
> 
> For the overlapping triangles problem, i've never seen that before... so
> maybe it is a problem in your code.

maybe, therefore I have attached a simple test case demonstrating the issue.
Moreover, this simple test case works fine as expected within the opengl 3.0 context and with other proprietary drivers (ati, nvidia) as well

For some reason the core version framebuffer does not have a depth buffer at all. I could not compile the test app (because of api differences happened in glm library) so I could not test which causes this, but I can see that there are several differences in OpenGLArea and OpenGLArea3 class implementation, not only the context version. Could you please 'minimize' these differences to see if it has impact (for example make glx_attrs content exactly the same in both cases)? From there is is much easier to figure out what could be the problem.

The problem is with the glxconfig that gets chosen. The application queries for compatible list of configs with glXChooseFBConfig and then blindly selects the first one. Although attributes for config query state GLX_DEPTH_SIZE 24, Mesa returns some configs that have depth size 0 and application selects one of those.

Just FYI: There are some GL apps out there that use depth buffering but don't bother to request a GLX visual with a depth buffer.  Topogun is one example.  
There's a DRI config option called "always_have_depth_buffer" which causes all visual types to be created with a depth buffer.

took some time to figure this out but the attributelist you pass to GLX (via glXChooseFBConfig) is broken, you should have attribute-value pairs, instead there is a single 'GLX_RGBA' in the middle of the list which screws things up badly. Take that GLX_RGBA away and things will work just fine.