BadGC with Find dialog

[Jerry James]

"Stephen J. Turnbull" <stephen at xemacs.org> wrote:
>>>>>> "Jerry" == Jerry James <james at xemacs.org> writes:
>
>     Jerry> Executive summary: The "Forward" button created by
>     Jerry> make-search-dialog (line 87 of lisp/dialog-items.el in
>     Jerry> current 21.5 CVS) feels like releasing its inverse_GC every
>     Jerry> time it is redisplayed.  Once it has been redisplayed a
>     Jerry> sufficient number of times, the reference count on that GC
>     Jerry> reaches zero and chaos ensues.  I am willing to bet
>     Jerry> doughnuts that the comment over x_button_redisplay in
>     Jerry> src/glyphs-x.c has something to do with it.  However, I do
>     Jerry> not actually know the source of the problem at this time.
>
> Oh, I bet I do.  XEmacs does its own GC caching because faces use lots
> of GCs.  Xt is obviously also doing GC caching internally, so every
> time the state of the button changes, the Xt decrements its cache
> refcount for the GC that gets swapped out.  XEmacs doesn't account for
> this, and so it does a simple assignment from its cache, which Xt
> can't see, rather than asking Xt for it.  So Xt doesn't increment its
> refcount when XEmacs uses the GC.

As far as I can see, the lwlib code does not use the internal GC
caching.  It appears to be used by redisplay-x.c only:

 - In x_bevel_area, it is used to manage top shadows, bottom shadows,
   and background GCs

 - In x_get_gc, to find a GC matching some characteristics.

 - In x_output_x_pixmap for purposes I don't understand.

 - In x_output_vertical_divider to find a background GC.

 - In x_flash, to swap foreground/background temporarily.

None of those functions appear in any of the backtraces I gathered.

> Why does this only cause problems for that dialog?  I'm glad you
> asked.  The reason is that lwlib doesn't know about faces, mostly.  So
> the cache maintained by XEmacs's src/xgccache.c (maintained with
> XCreateGC and XFreeGC) and used for faces doesn't intersect with Xt's
> cache (maintained with XtGetGC and XtReleaseGC), used by lwlib's
> Athena stuff.
>
> I'm willing to bet that we're calling XtReleaseGC on some face's
> cached GC.  I'm pretty busy the next few days though, so I'll post
> this guess for now.

That seems like a plausible guess, but it also doesn't seem to match the
information I've gathered so far.  Upon combing through the GDB output
some more, I have discovered several facts:

1) There are 7 widgets on the Find dialog.  One is a text field.  Two
   are the checkboxes "Match Case" and "Regular Expression".  The other
   4 are the buttons "Forwards", "Backwards", "Find Next", and "Cancel".

2) There are 3 GCs that are shared by the 2 checkboxes and 4 buttons.
   When the Find dialog is first created, all of them have reference
   count 6, as expected.

3) Only the "Forwards" and "Find Next" buttons do any GC manipulations
   after the dialog is created.  (I did not push any button other than
   "Find Next" during my tests.)  "Forwards" does such manipulations on
   each redisplay; "Find Next" does them only when pushed.

4) The "Forwards" button is first redisplayed immediately after the Find
   dialog is created, before any buttons can be pushed.  On each
   redisplay, "Forwards" does this (with the GCs mentioned above
   arbitrarily numbered 1, 2, and 3, and with a new one, 4, created
   during the first redisplay.)

                      GC
         1        2        3        4
      -------  -------  -------  -------
   a) Release
   b)          Release
   c)                            Allocate
   d)          Allocate
   e)                            Release
   f)          Release
   g)                            Allocate
   h)          Allocate
   i) Release
   j)          Release
   k)                            Allocate
   l)          Allocate
   m)                            Release
   n)          Release
   o)                            Allocate
   p)          Allocate
   q)                            Release
   r)          Release
   s)                            Allocate
   t)          Allocate
   u)                            Release
   v)          Release
   w)                            Allocate
   x)          Allocate

   So on every redisplay, the reference count on 1 goes down by 2, the
   reference counts on 2 and 3 stay the same, and the reference count on
   4 goes up by 1.  It looks to me like step "i" ought to be a release
   of 4 AND an allocate of 1 to keep things even.  This is redisplay,
   after all, and I haven't touched the button, so its appearance should
   not be changing.

5) The "Find Next" button does its manipulations as it is pushed, in
   order to reverse its colors as it is pushed down, then restore them
   when it comes back up.  It does this to the GCs numbered above, plus
   two new ones, 5 and 6, created while doing the pushing:

                      GC
         1        2        3        4        5        6
      -------  -------  -------  -------  -------  -------
   a)                   Release
   b)          Release
   c)                                     Allocate
   d)                                              Allocate
   e) Release
   f) Allocate
   g)                   Allocate
   h)                                     Release
   i) Release
   j)                                              Release
   k)                            Allocate
   l)          Allocate
   m)                   Release
   n)                   Allocate
   o) Allocate
   p)                            Release

   So on every push of "Find Next", the final GC refcounts are as they
   were before the push.

What is different about the "Forwards" button that makes it behave like
this, when all the other widgets seem to be behaving nicely?  "One of
these things is not like the others ..."

>     Jerry> Jerry "Brute Force" James, currently listening to
>     Jerry> Supertramp's "Breakfast in America"
>
> Excellent!  Nearly guarantees success, I should say.

:-)  Well, now I'm listening to Al Stewart's "Year of the Cat".  What
does *that* do to my chances, hey?
-- 
Jerry James, who thinks Mr. Stewart's instruments sound great, but
wishes that somebody who could sing, rather than talk, had recorded the
song