glewContextInit fails: glXGetCurrentDisplay is NULL

[tom fogal-2]

Hi, I'm having trouble trying to appropriately initialize a glX
context via GLEW.

The issue appears to be sourced in ``_glewInit_GLX_VERSION_1_2``, where
``glewGetProcAddress`` attempts to load ``glXGetProcAddress``.  The
``r`` variable in that function gets set to 0; ``glXGetProcAddress``
looks is a valid pointer, so seems somewhat valid.  However, calling
``glXGetProcAddress`` later returns NULL.  This happens almost
immediately after, in ``glxewContextInit``::

    /* query GLX version */
    glXQueryVersion(glXGetCurrentDisplay(), &major, &minor);

the program crashes in internal X functions from the above line (as you
might expect)::

    Program received signal SIGSEGV, Segmentation fault.
    0x00002b6d52942074 in XQueryExtension (dpy=0x0, name=0x2b6d527c1a2a
        "GLX", major_opcode=0x7fff62e37ae4, first_event=0x7fff62e37ae8,
        first_error=0x7fff62e37aec) at QuExt.c:46
    46          LockDisplay(dpy);
    Current language:  auto; currently c
    (gdb) bt
    #0  0x00002b6d52942074 in XQueryExtension (dpy=0x0,
        name=0x2b6d527c1a2a "GLX", major_opcode=0x7fff62e37ae4,
        first_event=0x7fff62e37ae8, first_error=0x7fff62e37aec)
        at QuExt.c:46
    #1  0x00002b6d5292ff8b in XInitExtension (dpy=0x0,
        name=0x2b6d527c1a2a "GLX") at InitExt.c:49
    #2  0x00002b6d55027eb1 in XextAddDisplay (extinfo=0x16deacf0,
        dpy=0x0, ext_name=0x2b6d527c1a2a "GLX", hooks=0x2b6d528d1180,
        nevents=17, data=0x0) at extutil.c:112
    #3  0x00002b6d5278745c in ?? () from /usr/lib64/libGL.so.1
    #4  0x00002b6d52779b99 in glXQueryVersion () from
        /usr/lib64/libGL.so.1
    #5  0x00002b6d4dd899f3 in glxewContextInit ()
        at glew/src/glew.c:8877

Interestingly, in the debugger, glXGetCurrentDisplay appears to be
valid::

    (gdb) p glXGetCurrentDisplay
    $1 = {<text variable, no debug info>} 0x2b6d5277a030
        <glXGetCurrentDisplay>
    (gdb) p (struct _XDisplay *)glXGetCurrentDisplay()
    $2 = (struct _XDisplay *) 0x16d980f0

I've tried printing ``getenv("DISPLAY")``, ``XOpenDisplay`` calls,
tested glXChooseVisual return values ... all seems in order.

The application in question uses a library called VTK under the hood to
do most rendering operations, including establishing a render window.
The window comes up, and through prints I've established that glX seems
to be initialized properly there.  GLEW initialization is done from a
different library, which is dynamically loaded at runtime, though GLEW
is also linked into the main executable.

That sounds a little confusing just reading it.  Here's a simple
diagram, where --> arrows indicate a compile-time link (i.e. via
-L/path/to/whatever -lthelib) and ..> arrows indicate a run-time link
(via dlopen)::

App
    --> VTK
        --> GL
    --> GLEW
    ..> libV
        --> GLEW

The GLEW linked in directly (i.e. not from ``libV``) doesn't appear to
be called ever; the debug prints I added to GLEW only show up once.

I'm using the NVIDIA drivers with Xorg 7.2, though I've tried loading
more recent client libraries (e.g. libxcb as libX11, from git) with the
same server as well. ``glxinfo`` gives this version info::

    server glx vendor string: NVIDIA Corporation
    server glx version string: 1.4
    client glx vendor string: NVIDIA Corporation
    client glx version string: 1.4
    OpenGL vendor string: NVIDIA Corporation
    OpenGL renderer string: GeForce 7800 GTX/PCI/SSE2
    OpenGL version string: 2.1.2 NVIDIA 173.14.12

This is an MPI application, though I feel like I've done a lot to
ensure it has the correct environment configured.  For now, I'm only
trying this with one process attempting to access the GPU, so there
should be no contention issues.

Any ideas what I'm doing wrong?

Thanks,

-tom

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
glew-users mailing list
glew-users@...
https://lists.sourceforge.net/lists/listinfo/glew-users

[Nigel Stewart-2]

>     OpenGL vendor string: NVIDIA Corporation
>     OpenGL renderer string: GeForce 7800 GTX/PCI/SSE2
>     OpenGL version string: 2.1.2 NVIDIA 173.14.12

Tom,

It might be worth trying a newer driver:

177.82 November 12, 2008
http://www.nvidia.com/object/linux_display_ia32_177.82.html

This problem is with GLEW 1.5.1?

- Nigel

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
glew-users mailing list
glew-users@...
https://lists.sourceforge.net/lists/listinfo/glew-users

[tom fogal-3]

Nigel Stewart <nstewart@...> writes:
>
> >     OpenGL vendor string: NVIDIA Corporation
> >     OpenGL renderer string: GeForce 7800 GTX/PCI/SSE2
> >     OpenGL version string: 2.1.2 NVIDIA 173.14.12
>
> Tom,
>
> It might be worth trying a newer driver:

<g>  Humorously, I was checking my email while I wait for the driver
to install... I was at 173 before.

> This problem is with GLEW 1.5.1?

Yes, sorry I did not specify.  I originally ran into the problem with
1.3.4, but I get the same behavior with 1.5.1.

I'll report back with the new driver's behavior.  Thanks,

-tom

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
glew-users mailing list
glew-users@...
https://lists.sourceforge.net/lists/listinfo/glew-users

[tom fogal-3]

tom fogal <tfogal@...> writes:

> Nigel Stewart <nstewart@...> writes:
> >
> > >     OpenGL vendor string: NVIDIA Corporation
> > >     OpenGL renderer string: GeForce 7800 GTX/PCI/SSE2
> > >     OpenGL version string: 2.1.2 NVIDIA 173.14.12
> >
> > It might be worth trying a newer driver:
>
> <g>  Humorously, I was checking my email while I wait for the driver
> to install... I was at 173 before.
>
> > This problem is with GLEW 1.5.1?
>
> Yes [. . .]
> I'll report back with the new driver's behavior.

I get the same crash using 177.82.  I'd like to recompile all the deps
to my application to be sure (esp. VTK), but they are linked to shared
objects so it should not make a difference.

(Anyone) Other ideas / changes I could make / things I could test?

-tom

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
glew-users mailing list
glew-users@...
https://lists.sourceforge.net/lists/listinfo/glew-users

[Nigel Stewart-2]

Tom,

> (Anyone) Other ideas / changes I could make / things I could test?

The documentation for glXGetCurrentDisplay states that if
no context is current, NULL is returned.  It seems to be that
glxewContextInit ought to just give up in this case, rather than
continue with glXQueryVersion.

Perhaps libV could be modified to defer calling glxewContextInit
until there is an OpenGL context?

- Nigel



-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
glew-users mailing list
glew-users@...
https://lists.sourceforge.net/lists/listinfo/glew-users

[Marcelo E. Magallón]

On Mon, Dec 8, 2008 at 9:45 PM, tom fogal <tfogal@...> wrote:

> Yes, sorry I did not specify.  I originally ran into the
> problem with 1.3.4, but I get the same behavior with 1.5.1.
>
> I'll report back with the new driver's behavior.  Thanks,

 Previously you said:

> The application in question uses a library called VTK under the
> hood to do most rendering operations, including establishing a
> render window.  The window comes up, and through prints I've
> established that glX seems to be initialized properly there.
> GLEW initialization is done from a different library, which is
> dynamically loaded at runtime, though GLEW is also linked into
> the main executable.

 This might be an issue.  At some point I had a modified version
 of GLEW that worked with, tsk, tsk, Quake.  The modification was
 needed because Quake dlopens libGL.  Basically you install GLEW
 as libGL and let it know where it can find the real libGL.

 Another issue might be the order of initialization: this other
 library that loads GLEW, is that done before or after the
 connection to the X server has been established?

 Marcelo

 PS: I got back my mail, yay!

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
glew-users mailing list
glew-users@...
https://lists.sourceforge.net/lists/listinfo/glew-users

[tom fogal-3]

"Marcelo E. Magallón" <mmagallo@...> writes:

> On Mon, Dec 8, 2008 at 9:45 PM, tom fogal <tfogal@...> wrote:
>
> > Yes, sorry I did not specify.  I originally ran into the
> > problem with 1.3.4, but I get the same behavior with 1.5.1.
>
>  Previously you said:
>
> > The application in question uses a library called VTK under the
> > hood to do most rendering operations, including establishing a
> > render window.  The window comes up, and through prints I've
> > established that glX seems to be initialized properly there.
> > GLEW initialization is done from a different library, which is
> > dynamically loaded at runtime, though GLEW is also linked into
> > the main executable.
>
>  This might be an issue.  At some point I had a modified version
>  of GLEW that worked with, tsk, tsk, Quake.  The modification was
>  needed because Quake dlopens libGL.  Basically you install GLEW
>  as libGL and let it know where it can find the real libGL.

VTK doesn't work like quake though -- it's not dynamically loading GL
or glX.  The GL and glX header files are included directly, though
glX symbols are left as undefined references since -l options are
missing on the library link line.  These are resolved when linking the
application, however.

>  Another issue might be the order of initialization: this other
>  library that loads GLEW, is that done before or after the
>  connection to the X server has been established?

The library (`libV`, from before) is dlopen()ed before the X connection
and glX context have been initialized.  However, glewInit() is not
called until these two have been established.  I was under the
impression this was appropriate usage, and furthermore I couldn't find
any `__attribute__ (("constructor"))'s in the GLEW source.

Have I missed something?

-tom


------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
glew-users mailing list
glew-users@...
https://lists.sourceforge.net/lists/listinfo/glew-users

[Marcelo E. Magallon]

On Tue, Dec 9, 2008 at 11:03 AM, tom fogal <tfogal@...> wrote:

> The library (`libV`, from before) is dlopen()ed before the X
> connection and glX context have been initialized.  However,
> glewInit() is not called until these two have been established.
>  I was under the impression this was appropriate usage, and
> furthermore I couldn't find any `__attribute__
> (("constructor"))'s in the GLEW source.
>
> Have I missed something?

 No, I don't think so.  Probably I am, though.

 Is the code multithreaded?  Is the connection with the X server
 established inside a different thread?  Could this be a race?
 The fact that when running under the debugger, everything works
 ok hints at a timing issue.

 I'm guessing wildly here.  You are using VTK with the Qt
 widgets, right? (I'm sorry if you already provided this
 information, I missed the start of the thread)  Can you
 reproduce the problem with a reduced code example?

 Marcelo

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
glew-users mailing list
glew-users@...
https://lists.sourceforge.net/lists/listinfo/glew-users

[tom fogal-3]

Marcelo <marcelo.magallon@...> writes:

> On Tue, Dec 9, 2008 at 11:03 AM, tom fogal <tfogal@...> wrote:
>
> > The library (`libV`, from before) is dlopen()ed before the X
> > connection and glX context have been initialized.  However,
> > glewInit() is not called until these two have been established.
> >  I was under the impression this was appropriate usage, and
> > furthermore I couldn't find any `__attribute__
> > (("constructor"))'s in the GLEW source.
> >
> > Have I missed something?
>
>  No, I don't think so.  Probably I am, though.
>
>  Is the code multithreaded?

My application is not multithreaded.

VTK has some multithreading stuff, but I'm not sure to what extent it
is used internally (5 years ago, it wasn't very much IIRC, but
knowledge from 5 years ago is a bit dated even if I *do* remember
correctly ;).  Certainly the implementation of the render window which
I have been reading / throwing debug statements in is not
multithreaded.

>  Is the connection with the X server established inside a different
>  thread?  Could this be a race?  The fact that when running under the
>  debugger, everything works ok hints at a timing issue.

If I had to guess, I would say it's some sort of shared library
loading issue.  I'm not linking things correctly, and so the dlopen()
doesn't realize there's already a copy of the s.o. in memory, and I
thus end up with *two* copies of GLEW in memory.

That's wild speculation though ...

>  I'm guessing wildly here.

Join the club ;)

>  You are using VTK with the Qt widgets, right? (I'm sorry if you
>  already provided this information, I missed the start of the thread)

You didn't miss it -- I didn't mention.  The application does
use some Qt widgets, however in the code path I am following no
GUI is brought up sans the render window.  Based on the code in
vtkXOpenGLRenderWindow, this window appears to be created through VTK
code, and so I don't think Qt is involved here.

>  Can you reproduce the problem with a reduced code example?

I will try to narrow things down.

After reading/responding to these emails, my current thought is
a program which creates a vtkXOpenGLRW and renders into it via a
`libwhatever', where `libwhatever' initializes GLEW and then draws a
quad or something dumb.  It'd probably be good to allow dynamically
loading `libwhatever' too, to see if that's the issue.  Not sure if
linking GLEW into the program directly (not only through libwhatever)
is relevant, yet..


Thanks,

-tom

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
glew-users mailing list
glew-users@...
https://lists.sourceforge.net/lists/listinfo/glew-users

[Felix Bellaby]

On Tue, 2008-12-09 at 10:51 -0700, tom fogal wrote:
> After reading/responding to these emails, my current thought is
> a program which creates a vtkXOpenGLRW and renders into it via a
> `libwhatever', where `libwhatever' initializes GLEW and then draws a
> quad or something dumb.  It'd probably be good to allow dynamically
> loading `libwhatever' too, to see if that's the issue.  Not sure if
> linking GLEW into the program directly (not only through libwhatever)
> is relevant, yet..

This kind of mess suggests that you might have multiple Display
connections on the go.

Felix


------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
glew-users mailing list
glew-users@...
https://lists.sourceforge.net/lists/listinfo/glew-users

[tom fogal-3]

tom fogal <tfogal@...> writes:
> Marcelo <marcelo.magallon@...> writes:
> > On Tue, Dec 9, 2008 at 11:03 AM, tom fogal <tfogal@...> wrote:
[snip]
> My application is not multithreaded.
>
> >  Can you reproduce the problem with a reduced code example?
>
> I will try to narrow things down.

I have done this.  Qt is, indeed, not relevant.  The example program
is available at:

    http://www.sci.utah.edu/~tfogal/glx/

I'm hoping someone can just look at the extracted source and say,
`hey, dummy, you forgot to call <X> at <Y>!', but I think I've included
everything needed to build.  The mesa 7.2 referenced in the makefile
is required because of VTK; it's actually not used, and the symbols
are mangled so I'm pretty sure about that.  VTK is a bit special [1],
but not in any way that should impact this.  I've also included my
Rendering/vtkXOpenGLRenderWindow.cxx, so you can see how I've verified
that the context / etc. is valid.

As a quick reminder, plus a summary of what this small program shows:
    . VTK creates / initializes the X window + GLX context
    . Context is valid just prior to calling glewInit
    . glewInfo dynamically loads glXGetProcAddress
    . Calling glXGetProcAddress returns NULL, causing a crash in
      XQueryExtension.
    . Dynamically loading libs does not seem to matter
    . glX context is valid as we leave VTK

Here's a backtrace with some of the last parts of the debugging
output:

    vtkXOpenGLRenderWindow (0x6312f0): [VTKDBG] virtual void
    vtkXOpenGLRenderWindow::WindowInitialize()
            disp name: :0.0
            disp id: 0x6315c0
            ctx: 0x646680
            cur ctx: 0x646680
            msg: about to initialize opengl ...
    Debug: In /local/visitdeps/VTK/Rendering/vtkOpenGLRenderWindow.cxx,
    line 122
    vtkXOpenGLRenderWindow (0x6312f0): [VTKDBG] virtual void
    vtkOpenGLRenderWindow::OpenGLInit()
            msg: initializing...
    Debug: In /local/visitdeps/VTK/Rendering/vtkOpenGLRenderWindow.cxx,
    line 161
    vtkXOpenGLRenderWindow (0x6312f0): [VTKDBG] virtual void
    vtkOpenGLRenderWindow::OpenGLInit()
            msg: initialization complete

    Program received signal SIGSEGV, Segmentation fault.
    [Switching to Thread 0x2b27a5ad0fc0 (LWP 26858)]
    0x00002b27a354db50 in XQueryExtension () from /usr/lib64/libX11.so.6
    (gdb) bt
    #0  in XQueryExtension () from /usr/lib64/libX11.so.6
    #1  in XInitExtension () from /usr/lib64/libX11.so.6
    #2  in XextAddDisplay () from /usr/lib64/libXext.so.6
    #3  in ?? () from /usr/lib64/libGL.so.1
    #4  in glXQueryVersion () from /usr/lib64/libGL.so.1
    #5  in glxewContextInit () from /scratch/sw/lib64/libGLEW.so.1.5
    #6  in render::init () at render.cc:19
    #7  in main () at main.cc:14

(addresses removed from the gdb part of the bt).

Does this help?  Any ideas what I'm messing up?  Further things I
could try?

Thanks!

-tom

[1] http://visitusers.org/index.php?title=VisIt_VTK_Modifications

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
glew-users mailing list
glew-users@...
https://lists.sourceforge.net/lists/listinfo/glew-users

[Nigel Stewart-2]

>     http://www.sci.utah.edu/~tfogal/glx/

Seems to work fine on Ubunutu 8.04.1 i686 ...
(With some modifications of the makefile)

- Nigel

$ make clean
rm -f main.o render.o vtk.o test

$ make
g++ -g -Wall -Wextra -Wno-deprecated -Werror -D_GLIBCXX_DEBUG
-I/scratch/sw/include
-I/local/visitdeps/visit/vtk/5.0.0c/linux-x86_64_gcc-4.2.1
-I/local/visitdeps/visit/vtk/5.0.0c/linux-x86_64_gcc-4.2.1/Rendering
-I/local/visitdeps/visit/vtk/5.0.0c/linux-x86_64_gcc-4.2.1/Common
-I/usr/include/vtk-5.0  -c -o main.o main.cc
g++ -g -Wall -Wextra -Wno-deprecated -Werror -D_GLIBCXX_DEBUG
-I/scratch/sw/include
-I/local/visitdeps/visit/vtk/5.0.0c/linux-x86_64_gcc-4.2.1
-I/local/visitdeps/visit/vtk/5.0.0c/linux-x86_64_gcc-4.2.1/Rendering
-I/local/visitdeps/visit/vtk/5.0.0c/linux-x86_64_gcc-4.2.1/Common
-I/usr/include/vtk-5.0  -c -o render.o render.cc
g++ -g -Wall -Wextra -Wno-deprecated -Werror -D_GLIBCXX_DEBUG
-I/scratch/sw/include
-I/local/visitdeps/visit/vtk/5.0.0c/linux-x86_64_gcc-4.2.1
-I/local/visitdeps/visit/vtk/5.0.0c/linux-x86_64_gcc-4.2.1/Rendering
-I/local/visitdeps/visit/vtk/5.0.0c/linux-x86_64_gcc-4.2.1/Common
-I/usr/include/vtk-5.0  -c -o vtk.o vtk.cc
g++ main.o render.o vtk.o -o test -L/scratch/sw/lib64 -lGLEW
-L/local/visitdeps/visit/vtk/5.0.0c/linux-x86_64_gcc-4.2.1/lib
-lvtkRendering -lvtkCommon -lvtkFiltering -lvtkGenericFiltering
-lvtkImaging -lvtksys -lvtkDICOMParser -lvtkGraphics -lvtkIO -lvtkftgl
-lvtkHybrid -lvtkVolumeRendering
-Wl,--rpath,/local/visitdeps/visit/vtk/5.0.0c/linux-x86_64_gcc-4.2.1/lib
-L/local/visitdeps/visit/mesa/7.2/linux-x86_64_gcc-4.2.1/lib64 -lGL
-lGLU
-Wl,--rpath,/local/visitdeps/visit/mesa/7.2/linux-x86_64_gcc-4.2.1/lib64

$ ./test
Debug: In /build/buildd/vtk-5.0.3/Rendering/vtkXOpenGLRenderWindow.cxx,
line 380
vtkXOpenGLRenderWindow (0x8064d18): Resizing the xwindow


Debug: In /build/buildd/vtk-5.0.3/Rendering/vtkXOpenGLRenderWindow.cxx,
line 422
vtkXOpenGLRenderWindow (0x8064d18):  Mapping the xwindow


GLEW initialized: 1.5.0

$

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
glew-users mailing list
glew-users@...
https://lists.sourceforge.net/lists/listinfo/glew-users

[tom fogal-3]

Nigel Stewart <nstewart@...> writes:
> >     http://www.sci.utah.edu/~tfogal/glx/
>
> Seems to work fine on Ubunutu 8.04.1 i686 ...
> (With some modifications of the makefile)
[snip]
> GLEW initialized: 1.5.0

*sigh* I was afraid of that.  Thanks (very much!) for going through
all the hassle of testing.

No obvious coding errors / GLEW setup errors?  If so, I'll upgrade my X
setup in an attempt to rule that out^in, and then create a bug
report with the X folks or NVIDIA.

Thanks,

-tom

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
glew-users mailing list
glew-users@...
https://lists.sourceforge.net/lists/listinfo/glew-users

[Nigel Stewart-2]

>> Seems to work fine on Ubunutu 8.04.1 i686 ...
>
> *sigh* I was afraid of that.  Thanks (very much!) for going through
> all the hassle of testing.

        I noticed the makefile is geared for x86_64.  Do you
        see the same problem in -m32 mode?  I don't have access
        to a 64-bit linux today, but I could try it tomorrow.

- Nigel

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
glew-users mailing list
glew-users@...
https://lists.sourceforge.net/lists/listinfo/glew-users

[Nigel Stewart-2]

>>> Seems to work fine on Ubunutu 8.04.1 i686 ...
>> *sigh* I was afraid of that.  Thanks (very much!) for going through
>> all the hassle of testing.

It also seems to work fine on Fedora 8 x86_64
using the vtk-5.0.4-23.99.fc8 RPM and the makefile
tweaked somewhat.  (Makefile is attached, include
vtk from /usr/include/vtk, eliminate various vtk link
libraries, link against -lGLU and -lGL rather than Mesa)

Valgrind does reveal some potential issues though...

Hope it helps somehow.

- Nigel

$ uname -a
Linux xxx.nvidia.com 2.6.26.6-49.fc8 #1 SMP Fri Oct 17 15:33:32 EDT 2008
x86_64 x86_64 x86_64 GNU/Linux

$ glxinfo
...
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce 6600 GT/PCI/SSE2
OpenGL version string: 2.1.2 NVIDIA 177.82
...

$ make
g++ -g -Wall -Wextra -Wno-deprecated -Werror -D_GLIBCXX_DEBUG
-I/scratch/sw/include -I/usr/include/vtk -I/usr/include/vtk/Rendering
-I/usr/include/vtk/Common  -c -o main.o main.cc
g++ -g -Wall -Wextra -Wno-deprecated -Werror -D_GLIBCXX_DEBUG
-I/scratch/sw/include -I/usr/include/vtk -I/usr/include/vtk/Rendering
-I/usr/include/vtk/Common  -c -o render.o render.cc
g++ -g -Wall -Wextra -Wno-deprecated -Werror -D_GLIBCXX_DEBUG
-I/scratch/sw/include -I/usr/include/vtk -I/usr/include/vtk/Rendering
-I/usr/include/vtk/Common  -c -o vtk.o vtk.cc
g++ main.o render.o vtk.o -o test -L/scratch/sw/lib64 -lGLEW
-L/usr/include/vtk/lib64 -lvtkRendering -lvtkCommon -lvtkFiltering
-lvtkGenericFiltering -lvtkImaging -lvtksys -lvtkDICOMParser
-lvtkGraphics -lvtkIO -lvtkHybrid -lvtkVolumeRendering
-Wl,--rpath,/usr/include/vtk/lib -L/usr/lib64 -lGLU -lGL
-Wl,--rpath,/local/visitdeps/visit/mesa/7.2/linux-x86_64_gcc-4.2.1/lib64

$ ./test
Debug: In
/builddir/build/BUILD/VTK/Rendering/vtkXOpenGLRenderWindow.cxx, line 380
vtkXOpenGLRenderWindow (0x10f9ed0): Resizing the xwindow


Debug: In
/builddir/build/BUILD/VTK/Rendering/vtkXOpenGLRenderWindow.cxx, line 422
vtkXOpenGLRenderWindow (0x10f9ed0):  Mapping the xwindow


GLEW initialized: 1.4.0

$ valgrind ./test
==24325== Memcheck, a memory error detector.
==24325== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==24325== Using LibVEX rev 1732, a library for dynamic binary translation.
==24325== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==24325== Using valgrind-3.2.3, a dynamic binary instrumentation framework.
==24325== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==24325== For more details, rerun with: -v
==24325==
Debug: In
/builddir/build/BUILD/VTK/Rendering/vtkXOpenGLRenderWindow.cxx, line 380
vtkXOpenGLRenderWindow (0x8930938): Resizing the xwindow


==24325== Conditional jump or move depends on uninitialised value(s)
==24325==    at 0x3B8B8DD1A3: _nv000094gl (in
/usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B92881D13: (within /usr/lib64/libGL.so.177.82)
==24325==    by 0x3B928828A7: (within /usr/lib64/libGL.so.177.82)
==24325==    by 0x3B9286A5C1: (within /usr/lib64/libGL.so.177.82)
==24325==    by 0x3B9286CB34: (within /usr/lib64/libGL.so.177.82)
==24325==    by 0x3B9286FA0D: (within /usr/lib64/libGL.so.177.82)
==24325==    by 0x3B92864837: glXCreateContext (in
/usr/lib64/libGL.so.177.82)
==24325==    by 0x4DD2989: vtkXOpenGLRenderWindow::WindowInitialize()
(in /usr/lib64/libvtkRendering.so.5.0.4)
==24325==    by 0x402C8E: vtk::init() (vtk.cc:9)
==24325==    by 0x4019CC: main (main.cc:13)
==24325==
==24325== Conditional jump or move depends on uninitialised value(s)
==24325==    at 0x3B8BA23076: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B8BA23D2C: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B8B5FB378: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B8B896AA8: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B8B623733: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B8B8D9F5D: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B9286A185: (within /usr/lib64/libGL.so.177.82)
==24325==    by 0x3B9286E86A: (within /usr/lib64/libGL.so.177.82)
==24325==    by 0x4DD1C0F: vtkXOpenGLRenderWindow::MakeCurrent() (in
/usr/lib64/libvtkRendering.so.5.0.4)
==24325==    by 0x4DD29AA: vtkXOpenGLRenderWindow::WindowInitialize()
(in /usr/lib64/libvtkRendering.so.5.0.4)
==24325==    by 0x402C8E: vtk::init() (vtk.cc:9)
==24325==    by 0x4019CC: main (main.cc:13)
==24325==
==24325== Conditional jump or move depends on uninitialised value(s)
==24325==    at 0x3B8BA2307B: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B8BA23D2C: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B8B5FB378: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B8B896AA8: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B8B623733: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B8B8D9F5D: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B9286A185: (within /usr/lib64/libGL.so.177.82)
==24325==    by 0x3B9286E86A: (within /usr/lib64/libGL.so.177.82)
==24325==    by 0x4DD1C0F: vtkXOpenGLRenderWindow::MakeCurrent() (in
/usr/lib64/libvtkRendering.so.5.0.4)
==24325==    by 0x4DD29AA: vtkXOpenGLRenderWindow::WindowInitialize()
(in /usr/lib64/libvtkRendering.so.5.0.4)
==24325==    by 0x402C8E: vtk::init() (vtk.cc:9)
==24325==    by 0x4019CC: main (main.cc:13)
==24325==
==24325== Conditional jump or move depends on uninitialised value(s)
==24325==    at 0x3B8BA230C6: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B8BA23D39: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B8B5FB378: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B8B896AA8: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B8B623733: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B8B8D9F5D: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B9286A185: (within /usr/lib64/libGL.so.177.82)
==24325==    by 0x3B9286E86A: (within /usr/lib64/libGL.so.177.82)
==24325==    by 0x4DD1C0F: vtkXOpenGLRenderWindow::MakeCurrent() (in
/usr/lib64/libvtkRendering.so.5.0.4)
==24325==    by 0x4DD29AA: vtkXOpenGLRenderWindow::WindowInitialize()
(in /usr/lib64/libvtkRendering.so.5.0.4)
==24325==    by 0x402C8E: vtk::init() (vtk.cc:9)
==24325==    by 0x4019CC: main (main.cc:13)
==24325==
==24325== Conditional jump or move depends on uninitialised value(s)
==24325==    at 0x3B8BA230CB: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B8BA23D39: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B8B5FB378: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B8B896AA8: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B8B623733: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B8B8D9F5D: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B9286A185: (within /usr/lib64/libGL.so.177.82)
==24325==    by 0x3B9286E86A: (within /usr/lib64/libGL.so.177.82)
==24325==    by 0x4DD1C0F: vtkXOpenGLRenderWindow::MakeCurrent() (in
/usr/lib64/libvtkRendering.so.5.0.4)
==24325==    by 0x4DD29AA: vtkXOpenGLRenderWindow::WindowInitialize()
(in /usr/lib64/libvtkRendering.so.5.0.4)
==24325==    by 0x402C8E: vtk::init() (vtk.cc:9)
==24325==    by 0x4019CC: main (main.cc:13)
Debug: In
/builddir/build/BUILD/VTK/Rendering/vtkXOpenGLRenderWindow.cxx, line 422
vtkXOpenGLRenderWindow (0x8930938):  Mapping the xwindow


GLEW initialized: 1.4.0
==24325==
==24325== Invalid read of size 8
==24325==    at 0x3B8B94B4A3: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B8B60E812: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B8B9BACA4: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B8B8C865B: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B8B8C8D67: (within /usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B8B8A3D56: _nv000133gl (in
/usr/lib64/libGLcore.so.177.82)
==24325==    by 0x3B92872E0B: (within /usr/lib64/libGL.so.177.82)
==24325==    by 0x3B92872F8B: _fini (in /usr/lib64/libGL.so.177.82)
==24325==    by 0x3DEA40DC73: _dl_fini (in /lib64/ld-2.7.so)
==24325==    by 0x3DEB634028: exit (in /lib64/libc-2.7.so)
==24325==    by 0x3DEB61E07A: (below main) (in /lib64/libc-2.7.so)
==24325==  Address 0x8911678 is 192 bytes inside a block of size 256 free'd
==24325==    at 0x4A04F99: operator delete[](void*)
(vg_replace_malloc.c:256)
==24325==    by 0x51928A3:
vtkInstantiatorHashTable::~vtkInstantiatorHashTable() (in
/usr/lib64/libvtkCommon.so.5.0.4)
==24325==    by 0x5192947: vtkInstantiator::ClassFinalize() (in
/usr/lib64/libvtkCommon.so.5.0.4)
==24325==    by 0x3DEB63432C: __cxa_finalize (in /lib64/libc-2.7.so)
==24325==    by 0x5146205: (within /usr/lib64/libvtkCommon.so.5.0.4)
==24325==    by 0x51FB3A0: (within /usr/lib64/libvtkCommon.so.5.0.4)
==24325==    by 0x3DEB634028: exit (in /lib64/libc-2.7.so)
==24325==    by 0x3DEB61E07A: (below main) (in /lib64/libc-2.7.so)
==24325==
==24325== ERROR SUMMARY: 12 errors from 6 contexts (suppressed: 6 from 1)
==24325== malloc/free: in use at exit: 316,940 bytes in 42 blocks.
==24325== malloc/free: 3,063 allocs, 3,021 frees, 4,224,975 bytes allocated.
==24325== For counts of detected errors, rerun with: -v
==24325== searching for pointers to 42 not-freed blocks.
==24325== checked 7,956,448 bytes.

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

CF=-g -Wall -Wextra -Wno-deprecated -Werror
GLEW_PFX=/scratch/sw
GLEW_CPPFLAGS=-I$(GLEW_PFX)/include
GLEW_LDFLAGS=-L$(GLEW_PFX)/lib64 -lGLEW

VTK_PFX=/usr/include/vtk
VTK_CPPFLAGS=-I$(VTK_PFX) -I$(VTK_PFX)/Rendering -I$(VTK_PFX)/Common
VTK_LDFLAGS=-L/usr/lib -lvtkRendering -lvtkFiltering -lvtkfreetype \
                        -lvtkImaging -lvtkftgl -lvtkIO -lvtkpng -lvtkzlib -lvtkjpeg \
                        -lvtkexpat -lvtkCommon
VTK_LDFLAGS=-L$(VTK_PFX)/lib64 -lvtkRendering \
                        -lvtkCommon -lvtkFiltering -lvtkGenericFiltering -lvtkImaging \
                        -lvtksys -lvtkDICOMParser \
                        -lvtkGraphics -lvtkIO \
                        -lvtkHybrid -lvtkVolumeRendering \
                        -Wl,--rpath,$(VTK_PFX)/lib

MESA_PFX=/local/visitdeps/visit/mesa/7.2/linux-x86_64_gcc-4.2.1
MESA_LDFLAGS=-L/usr/lib64 -lGLU -lGL \
                         -Wl,--rpath,$(MESA_PFX)/lib64

CPPFLAGS=$(GLEW_CPPFLAGS) $(VTK_CPPFLAGS)
LDFLAGS=$(GLEW_LDFLAGS) $(VTK_LDFLAGS) $(MESA_LDFLAGS)
CXXFLAGS:=$(CF) -D_GLIBCXX_DEBUG
SRC=main.cc render.cc vtk.cc
OBJ:=$(SRC:.cc=.o)

all: $(OBJ) test

test: $(OBJ)
        $(CXX) $^ -o test $(LDFLAGS)

clean:
        rm -f $(OBJ) test

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
glew-users mailing list
glew-users@...
https://lists.sourceforge.net/lists/listinfo/glew-users

[tom fogal-3]

Nigel Stewart <nstewart@...> writes:
> >>> Seems to work fine on Ubunutu 8.04.1 i686 ...
> >> *sigh* I was afraid of that.  Thanks (very much!) for going through
> >> all the hassle of testing.
>
> It also seems to work fine on Fedora 8 x86_64
> using the vtk-5.0.4-23.99.fc8 RPM and the makefile
> tweaked somewhat.
[snip]

Thanks, I'll take a look at this soon, looks like I've got some time
Friday afternoon.

> Valgrind does reveal some potential issues though...

You need to use --smc-check=all with the nvidia drivers -- they use
self modifying code, apparently.


Thanks again,

-tom

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
glew-users mailing list
glew-users@...
https://lists.sourceforge.net/lists/listinfo/glew-users

[tom fogal-3]

Hi all.  Apologies on the slow response to this.  Since it's been so
long, you might want a refresher; the thread starts here:

    http://www.nabble.com/glewContextInit-fails:-glXGetCurrentDisplay-is-NULL-td20906479.html

Nigel Stewart <nstewart@...> writes:
> >>> Seems to work fine on Ubunutu 8.04.1 i686 ...
> >> *sigh* I was afraid of that.  Thanks (very much!) for going through
> >> all the hassle of testing.
>
> It also seems to work fine on Fedora 8 x86_64
> using the vtk-5.0.4-23.99.fc8 RPM and the makefile
> tweaked somewhat.  (Makefile is attached, include
> vtk from /usr/include/vtk, eliminate various vtk link
> libraries, link against -lGLU and -lGL rather than Mesa)

I think you hit the nail on the head with this.  Summary of the text
below: linking both my system libGL (nvidia's) *and* Mesa into the same
app causes the issue.

I've simplified the test app; still available at the same location:

    http://www.sci.utah.edu/~tfogal/glx/

Most notably, I've eliminated any sort of dependence on VTK, making it
much easier to quickly test for the error.  Since the application
does not utilize a VTK which is compiled against mangled mesa, the
link line no longer requires a link against mesa.  The makefile has
been modified to build both `test-std' and `test-mgl', which are
identical except that the latter includes options to link Mesa in.

By now you're probably thinking it's some sort of library conflict
error; both libraries are defining glXGetCurrentDisplay, and for some
reason we end up calling the wrong one.  However, the Mesa I'm using
has only `mangled' symbols in it:

    http://mesa3d.org/mangling.html

So it seems like the symbols can't / do not overlap:

    $ M=/local/visitdeps/visit/mesa/7.2/linux-x86_64_gcc-4.2.1/lib64
    $ nm -A ${M}/libMesaGL.so ${M}/libOSMesa.so | grep glVertex3fv
    .../libMesaGL.so:000000000024d830 T mglVertex3fv
    $ nm -A ${M}/libMesaGL.so ${M}/libOSMesa.so | grep glXGetCurrentDisplay
    .../libMesaGL.so:0000000000046110 T glXGetCurrentDisplayEXT
    .../libMesaGL.so:00000000000460f0 T mglXGetCurrentDisplay

`ldd' confirms the library paths one would expect.  GLEW is linked
against my system OpenGL, which surprised me a little bit:

    $ ldd /scratch/sw/lib64/libGLEW.so.1.5 | grep GL
    ldd: warning: you do not have execution permission for `/scratch/sw/lib64/libGLEW.so.1.5'
    libGLU.so.1 => /usr/lib64/libGLU.so.1
    libGL.so.1 => /usr/lib64/libGL.so.1
    libGLcore.so.1 => /usr/lib64/libGLcore.so.1

I assumed it was dlopen()ing under the hood.  Mea culpa.

Valgrind-3.4.0 (currently a release candidate) thinks `test-std' is
clean.  It reports a couple issues for `test-mgl':

    1. As you might guess, an `invalid read of size 8' on the line
       causing the segmentation fault.
    2. Parameter to syscall writev() points to uninitialized bytes.
       This is sourced from the XStoreName call, which eventually
       calls write_vec (still in Xlib-XCB).
       Interestingly, if I comment out the XStoreName call, I get the
       identical error on the XResizeWindow call (which comes
       immediately afterwards).  This is probably because the error
       is in the synchronization code, and both calls seem to cause a
       synchronization step (but I'm no X developer).
       See `context.cc'.

I can't remember if it was publicly or not, but it was requested that
I attempt this in 32bit mode as well.  I've been having issues with
getting that working well on this distro, so unfortunately haven't been
able to try this yet.

I've heard reports of other people running into a GLEW-initialization
crash which I think is the same bug.  Interestingly, they were on OS
X systems.  They were using glut for window/context management, which
I guess is sort of ambiguous on OS X because glut can have different
backend implementations (e.g. X11, Carbon/Cocoa/<insert appropriate OS
X framework here>, etc.).  I hope to get an update on that during the
middle of next week.

Any ideas what's going on?
Ideas for more tests to help narrow it down even more?
Other comments?

Thanks,

-tom

------------------------------------------------------------------------------
_______________________________________________
glew-users mailing list
glew-users@...
https://lists.sourceforge.net/lists/listinfo/glew-users

[tom fogal-3]

Nigel Stewart <nstewart@...> writes:
> >> Seems to work fine on Ubunutu 8.04.1 i686 ...
> >
> > *sigh* I was afraid of that.  Thanks (very much!) for going through
> > all the hassle of testing.
>
> I noticed the makefile is geared for x86_64.  Do you
> see the same problem in -m32 mode?  I don't have access
> to a 64-bit linux today, but I could try it tomorrow.

Just to follow up here ..

With the trimmed-down test program I posted earlier this week, I found
this a lot easier to try on my laptop @ home.  This is a Core 2 duo but
a 32 bit system (.. bleh).  It's got a different GPU but still nvidia,
and still version 177.82 (err, not at home right now, but it was 177
and the latest as of this weekend, I'm sure).

It also exhibits the problem with `test-mgl'.  So I don't think it's a
64 vs. 32 bit issue, but some sort of library issue.  I'm starting to
think I need to write my own GLX dispatch library which would dlopen
the appropriate glX library after startup, but I haven't tested that
yet...

-tom

------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
glew-users mailing list
glew-users@...
https://lists.sourceforge.net/lists/listinfo/glew-users

[tom fogal-3]

Replying to my own email here ...

tom fogal <tfogal@...> writes:
[snip]

> Nigel Stewart <nstewart@...> writes:
> > >>> Seems to work fine on Ubunutu 8.04.1 i686 ...
> > >> *sigh* I was afraid of that.  Thanks (very much!) for going through
> > >> all the hassle of testing.
> >
> > It also seems to work fine on Fedora 8 x86_64
> > using the vtk-5.0.4-23.99.fc8 RPM and the makefile
> > tweaked somewhat.  (Makefile is attached, include
> > vtk from /usr/include/vtk, eliminate various vtk link
> > libraries, link against -lGLU and -lGL rather than Mesa)
>
> I think you hit the nail on the head with this.  Summary of the text
> below: linking both my system libGL (nvidia's) *and* Mesa into the same
> app causes the issue.

I have narrowed down the cause here, and feel like I know a solution.
In a nutshell, GLEW doesn't support mangled Mesa.

> I've simplified the test app; still available at the same location:
>
>     http://www.sci.utah.edu/~tfogal/glx/
[snip]

> The makefile has been modified to build both `test-std' and
> `test-mgl', which are identical except that the latter includes
> options to link Mesa in.
>
> By now you're probably thinking it's some sort of library conflict
> error; both libraries are defining glXGetCurrentDisplay, and for some
> reason we end up calling the wrong one.  However, the Mesa I'm using
> has only `mangled' symbols in it:
>
>     http://mesa3d.org/mangling.html

The mangling is exactly the issue.  GLEW provides all of the GL symbols
and loads them via the architecture's windowing system function loader
(so, on linux, `glXGetProcAddress'; on windows, there's some wgl
equivalent).  Loading it via the window-binding library (as opposed to
libGL) is a Good Thing, as far as I can gather.  Plus it avoids the
portability issues of loading symbols from a library.

The issue is in the context handling when using mangled Mesa as
your OpenGL implementation.  Mangling Mesa also mangles glX calls
(rightly; explained later).  So your typical user (read: Tom Fogal)
defines USE_MGL_NAMESPACE when compiling the relevant part of his
application, and doing so causes his glX initialization code to call
`mglXCreateContext', `mglXMakeCurrent', etc.  He also links against
GLEW.

GLEW is, however, compiled against the *system* libGL, which almost
definitely is not mangled.  Further, glxewContextInit calls:

    glXQueryVersion(glXGetCurrentDisplay(), &major, &minor);

.. and where do those glX calls get resolved?  Well, we didn't mangle
Mesa while compiling GLEW ... so they came from my system libGL.  Yet
I established my glX context through *Mesa's* glX routines.  Chaos
ensues.. or at least a segfault.


Ugh, it's too late to get into solutions right now.  I've got an idea,
but it needs 20 minutes of thought and then an hour or two of effort to
verify it'd work.  I'll follow up `real soon now'.
Plus, I think that discussion is more appropriate for glew-coders, so
splitting the discussion up let's us move there.

Cheers,

-tom

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
glew-users mailing list
glew-users@...
https://lists.sourceforge.net/lists/listinfo/glew-users

[Nigel Stewart-2]

Tom,

So glad to hear you got to the bottom of that problem!

- Nigel

> .. and where do those glX calls get resolved?  Well, we didn't mangle
> Mesa while compiling GLEW ... so they came from my system libGL.  Yet
> I established my glX context through *Mesa's* glX routines.  Chaos
> ensues.. or at least a segfault.


-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
glew-users mailing list
glew-users@...
https://lists.sourceforge.net/lists/listinfo/glew-users