OpenGL 3 context support in gldb-gui

  • Anonymous - 2011-08-22


    I've built Bugle on Fedora 16 x64 and while I can successfully run glxgears in it, it fails to run any application whose OpenGL context has been created using the GLX_create_context extension.

    For instance:

    The hosted application crashes (window silently disappears) as soon as glXMakeCurrent() is invoked on such context.

    Any idea of the cause of this issue?

    Thank you,

  • Bruce Merry

    Bruce Merry - 2011-08-22


    The explanation is almost certainly that I haven't really been keeping BuGLe up to date with GL changes for the last few years due to lack of time. This doesn't seem like it should be too difficult to add support for (at least the GLX variant). I'll take a look at it this week.


  • Bruce Merry

    Bruce Merry - 2011-08-24

    I've checked some work on this into svn - I don't actually have the extension on my home machine and I'm having a few issues with testing it remotely, but I give it about a 40% chance of working right (or at least better than it was). Give it a spin and let me know if it's working for you.

  • Anonymous - 2011-08-28

    Hi Bruce,

    First of all, thank you a lot for answering my query. Today, I compiled the latest SVN release (1030) and ran the aforementioned test but unfortunately, I'm still experiencing the same issue. Is there anything I can do to help you with this?

    Thanks again,

  • Bruce Merry

    Bruce Merry - 2011-08-28

    Probably the most useful thing would be a sample program I can build and run. At the moment I don't have any programs that use GLX_ARB_create_context other than the trivial program I wrote for testing the tracing. It would also help to know what you're doing with bugle - are you running the program in gldb-gui, or using some other filters?

  • Anonymous - 2011-08-28


    You can use the reference program available on the OpenGL wiki page:

    When I run it within gldb-gui, it crashes immediately after invoking glXMakeCurrent(). If I run it standalone, it works as expected.

    Thanks for your support,

  • Bruce Merry

    Bruce Merry - 2011-08-29

    Thanks for the link. I've tried that program, and unfortunately I'm not able to reproduce the crash. I am seeing some issues with the program getting stuck during shutdown (which may well be related if its due to memory corruption), but unfortunately the issue vanishes when I try to recreate it under valgrind or gdb.

    Some things that you can try:
    1. Did you install the version you built from r1030? I've been bitten in the past by just building locally and then running the locally built bin/gldb-gui, forgetting that this will still pick up libraries and plugins from the system installation directory.
    2. Does the issue occur with filtersets other than the debugger e.g. if you use the sample ~/.bugle/filters and run it with BUGLE_CHAIN=trace ./create_context, does it crash similarly? If so that'll make it easier to get a stack trace.
    3. The following might also help with obtaining a stack trace:
    a) In src/platform/posix/platform/threads.h, add "#define DEBUG_CONSTRUCTOR 1" (right above the code that tests it - line 90).
    b) Build and install as usual (also passing config=debug to scons on both build and install is a good idea to get symbols)
    c) Start the program inside gdb.
    d) In gdb do "set env" and "set env BUGLE_DEBUGGER_PORT=9118" and "set env BUGLE_DEBUGGER=tcp".
    e) Start the program. It will then wait for a TCP connection.
    f) Start gldb-gui. Under Options -> Target, select "Remote via TCP/IP". Then go Run -> Run. You're now debugging the program over a TCP/IP connection. Hopefully, it will crash inside the gdb session and you can get a backtrace.

    Hope that gets somewhere

  • Anonymous - 2011-09-12

    Hi Bruce,

    Sorry for not replying sooner. To answer your question, I installed r1030 before using it. I also built a debug version with the DEBUG_CONSTRUCTOR flag enabled and ran it trough gdb and TCP/IP as you suggested. Here is the outcome:

    Various printf()s from the test application

    Direct GLX rendering context obtained
    Making context current

    Program received signal SIGSEGV, Segmentation fault.
    0x00007ffff7d40c5a in tokenise (str=0x0, tokens=0x7d93f8)
        at src/gl/glextensions.c:53
    53     tmp = BUGLE_NMALLOC(strlen(str) + 1, char);
    (gdb) backtrace
    #0  0x00007ffff7d40c5a in tokenise (str=0x0, tokens=0x7d93f8)
        at src/gl/glextensions.c:53
    #1  0x00007ffff7d40e42 in context_init (key=0x74a608, data=0x7d93f0)
        at src/gl/glextensions.c:91
    #2  0x00007ffff7c9e30d in bugle_object_new (klass=0x658340, key=0x74a608,
        make_current=1 '\001') at src/objects.c:126
    #3  0x00007ffff7d3f189 in trackcontext_callback (call=0x7fffffffdf00,
        data=0x7fffffffde80) at src/glwin/trackcontext.c:308
    #4  0x00007ffff7c9b941 in filters_run (call=0x7fffffffdf00)
        at src/filters.c:722
    #5  0x00007ffff7c9a3ed in budgie_interceptor (call=0x7fffffffdf00)
        at src/interceptor.c:222
    #6  0x00007ffff7d3b4ab in glXMakeCurrent (arg0=0x602650, arg1=48234498,
        at build/gcc_gcc_gl_glx_x11_posix_debug/budgielib/lib.c:77736
    #7  0x0000000000401632 in main ()

    Hope this information is helpful,

  • Bruce Merry

    Bruce Merry - 2011-09-13

    Just after posting, I realized that the issue I'm experiencing may be related to this:

    Good catch! After seeing your post the debug trace immediately pointed at glGetString(GL_EXTENSIONS) being the culprit, but I couldn't see why it would be returning NULL for you. I assume you modified the create_context example app to ask for a core context? I can probably reproduce that once I'm back on a machine that has GL3 support.

    I'm sure this is far from the only issue that BuGLe will have with core contexts, but in this case it shouldn't be too hard to work around. There are going to be far more serious issues with the extension management due to BuGLe assuming that all GL versions are backwards compatible with previous versions.

  • Bruce Merry

    Bruce Merry - 2011-09-18

    I've just checked in r1031 which fixes the extension parser to use the GL3-style approach to querying the available extensions. It won't magically make all of bugle work on a forward-compatible context (in particular, I expect gldb-gui to explode since it will try to query all the legacy state), but it will hopefully fix that particular crash. Let me know if it works for you.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks