Re: [Xcircuit-dev] xcircuit Q&A

[Bryce D. <br...@tl...>]

Thanks for the netlisting ideas.  I'll try them.

On Wed, 24 Apr 2002, R. Timothy Edwards wrote:
> > I'm using xcircuit 2.5.2.  Later versions are crashing on startup with an
> > XQueryColors error.  I filed that one too. :)
> 
> Yuck.  I may need to see the actual error result, but try this:  xcircuit.c,
> routine "findnearcolor" (around line 1807), add as the first executable code
> after the type declarations:
> 
>    if (ncolors > 256) {
>       XQueryColor(dpy, cmap, cvexact);
>       return cvexact->pixel;
>    }
> 
> The rest of the stuff in that routine was supposed to be dealing with
> indexed color;  it is not relevant to 24- or 32- bit TrueColor visuals,
> and I suspect that's the problem.  But it could be something else.

I have 8 bit color, so that didn't help.  In fact findnearcolor() is never
called at all before it crashes.

I did a lot of gdb tracing and the complete results are at
http://sourceforge.net/tracker/index.php?func=detail&aid=548152&group_id=4952&atid=104952

The problem in 2.5.3 is because BBOXCOLOR was not initialized, but it
looks like you already fixed that in 2.5.4.

In 2.5.4, xc_alloccolor("Gray90") is returning a trash value of 135109808.
It calls CvtStringToPixel(NULL, &zval, &fromC, &toC) with
 fromC={size = 6, addr = 0x80c72aa "Gray90"}

That calls XAllocNamedColor(dpy, cmap, (char *)fromVal->addr,
                      &cvcolor, &cvexact)
which returns zero and goes to 
XLookupColor(dpy, cmap, (char *)fromVal->addr, &cvexact, &cvcolor)
which does not return zero, so it does
  cvcolor.pixel = cvexact.pixel;
but cvexact.pixel is 135109808.  There's the trash value.

If I change the "cvcolor.pixel = cvexact.pixel" line back to what it was
in previous versions:
  cvcolor.pixel = findnearcolor(&cvexact);
then 2.5.4 starts up fine with no X errors.

That should help to narrow it down.  See the SF bug report for more
details.

Regards,
Bryce