Re: [GtkGLExt] BadColor

["Jason Newton" <nevion gmail com>]

> I am seeing a problem where my application gets a "BadColor" X Window System
>
>
> error, and exits.  I can make the problem go away with the
> '--gdk-gl-no-standard-colormap' option.
>
> It does depend on what GL visual I request.  But it also doesn't happen
> consistently:  I have to run a program many times before the error starts
>
> occuring, and then it occurs consistently until I shutdown and restart X.
> Now that I've restarted X, I'm having trouble reproducing it, but I've seen it
> many times in the past, ever since I started using gtkglext.
>
>
> It apparently has something to do with the 'XmuLookupStandardColormap()' call.
> Any ideas what is happening here?  I'm starting to just put the following in
> my code to be safe, but its a kludge:
>
>   putenv("GDK_GL_NO_STANDARD_COLORMAP=1");
>   gdk_gl_init(&argc, &argv);
>
> -bryan

I have the same problem.  I'm on ubuntu edgy amd64 with fglrx 8.32.5 and mesa.  Interestingly, if I use mesa, I get no problems ever.  However with fglrx drivers...   if I set GDK_GL_NO_STANDARD_COLORMAP I get no problems ever.  If I don't though, I can run a threaded program I'm deving once with no errors reported and a clean exit in each of single buffer and double buffered modes, and then I get this every subsequent time until I restart x:
The error was 'BadColor (invalid Colormap parameter)'.
  (Details: serial 172 error_code 12 request_code 1 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)


When Gtk::Main ctor is ran after initing gtk/gtkgl.  The problem is created seemingly only when I use a threaded program I've built, however after words, I can't use any gtkgl program (including simpler single threaded ones).  glxgears/mplayer still run fine with no tweaking/abnormal behavior though.  This is completely consistant, and I've driven myself nuts trying to see if there's a racing condition or activity going on which needs to be hold the gdk thread lock... but everything looks like its exiting properly and nothing I try brings about any change...  And as I've said before, mesa says nothing (even when using dbg versions of all relavent libs). Any input on this?