glew and two dlopened libraries.

[Zeydlitz]

I have a two libraries A.so and B.so with similar code. They both shared common part:

#include <GL/glew.h>
#include <GL/gl.h>
#include <GL/glx.h>

        inline void* wglGetProcAddress(const char* x) {
                return (void*)glXGetProcAddress((const GLubyte*)x);
        }

#include <Cg/cg.h>
#include <Cg/cgGL.h>

u32 s_uFramebuffer = 0;

int AreYouHere() {

   return CodeNumber;
}

int Create() {
        CreateWindow();
  int const glew_ok = glewInit();
        if( glew_ok != GLEW_OK ) {
                ERROR_LOG("glewInit() is not ok!\n");
                return false;
        }

       if (glewIsSupported("GL_EXT_framebuffer_object"))
                return false;

        GL_REPORT_ERROR();
        if( err != GL_NO_ERROR )
                return false;

        glGenFramebuffersEXT( 1, &s_uFramebuffer);
       
       Do_some_job()
}

And I use them as shared libraries in main project. They both working and do a some sort of glX and Cg hard work. But! There is something wrong here, if I change them in runtime. The flow is following:

Main program to dlopen(A.so, RTLD_NOW), then map AreYouHere and call it. Then Create could be used, or no, it's unimportant.
User change library, and new dlopen(B.so, RTLD_NOW), AreYouHere used. And, finally, when Create() used, it segfaulted on glGenFramebuffersEXT -- at this time this function exists
($1 = {<text variable, no debug info>} 0xb02a6690 <glGenFramebuffersEXT>).

This code was written few years ago and not by me. But I does not see what's wrong here.

[tom fogal-3]

Zeydlitz <Zeydlitz@...> writes:

>
> I have a two libraries A.so and B.so with similar code. They both shared
> common part:
>
> #include <GL/glew.h>
> #include <GL/gl.h>
> #include <GL/glx.h>
>
> inline void* wglGetProcAddress(const char* x) {
> return (void*)glXGetProcAddress((const GLubyte*)x);
> }

Why are you shadowing the builtin wgl function (I haven't read the
wgl spec, but I'm assuming this function is the equivalent of the glX
function it calls)?

> #include <Cg/cg.h>
> #include <Cg/cgGL.h>
>
> u32 s_uFramebuffer = 0;
>
> int AreYouHere() {
>
>    return CodeNumber;
> }
>
> int Create() {
>         CreateWindow();
>   int const glew_ok = glewInit();
> if( glew_ok != GLEW_OK ) {
> ERROR_LOG("glewInit() is not ok!\n");
> return false;
> }

You are returning `false' in a type-integer function.

>        if (glewIsSupported("GL_EXT_framebuffer_object"))
>                 return false;

Again.

>
> GL_REPORT_ERROR();
> if( err != GL_NO_ERROR )
>                 return false;

Again.

> glGenFramebuffersEXT( 1, &s_uFramebuffer);
>        
>        Do_some_job()
> }

This function has no return value in the default case, though it looks
like you simplified it for the email.

> And I use them as shared libraries in main project. They both working and do
> a some sort of glX and Cg hard work. But! There is something wrong here, if
> I change them in runtime. The flow is following:
>
> Main program to dlopen(A.so, RTLD_NOW), then map AreYouHere and call it.
> Then Create could be used, or no, it's unimportant.
> User change library, and new dlopen(B.so, RTLD_NOW), AreYouHere used. And,
> finally, when Create() used, it segfaulted on glGenFramebuffersEXT

You probably don't have a valid GL context when glewInit is called.

> -- at this time this function exists
> ($1 = {<text variable, no debug info>} 0xb02a6690 <glGenFramebuffersEXT>).

You're probably printing out the wrong variable when you're in gdb;
it's hard to actually print what you're looking for, since many
variables are shadowed, and macros abound which aren't `visible' / in
effect while within gdb.  I've found prints to work better than gdb,
when debugging GLEW.


Dig a little deeper and verify you have a context, and then break on
some of the symbol resolution code in GLEW.  Make sure you're not
getting NULL pointers.  Report back either way.  The most likely
explanation is that you have no context.  Might be the glewIsSupported
`if' isn't firing when it should, but that's unlikely.

Or you're hitting the issue I am, but that would surprise me.

-tom

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
glew-users mailing list
glew-users@...
https://lists.sourceforge.net/lists/listinfo/glew-users