BadGC with Find dialog

[Glynn Clements]

Jerry James wrote:

> >     >> ... which probably means recompiling XFree86, right?
> >
> >     Glynn> Um, probably. Unless you want to disassemble libXaw.so and
> >     Glynn> manually work out which functions those addresses really
> >     Glynn> correspond to.
> >
> > Debian provides -dbg packages for all libraries it distributes AFAIK,
> > maybe Red Hat does too?  Ask Jens Petersen.
> 
> RedHat does not.  For reasons I couldn't find discussed anywhere,
> they've had trouble making the X build work with their debuginfo
> packages.  Last night I finally got around to recompiling my X
> libraries.  Here's a backtrace that seems to make more sense:
> 
> #0  0x42074945 in _int_free () from /lib/tls/libc.so.6
> #1  0x42073908 in free () from /lib/tls/libc.so.6
> #2  0x40233dab in XFreeGC (dpy=0x86ad580, gc=0x89075f8) at FreeGC.c:46
> #3  0x401cbdf5 in XtReleaseGC (widget=0x893f508, gc=0x89075f8)
>     at GCManager.c:307
> #4  0x400a7321 in XawCommandSetValues (current=0xbfffd310, request=0xbfffcff0, 
>     cnew=0x893f508, args=0xbfffd660, num_args=0xbfffcdc4) at Command.c:542
> #5  0x401e19d2 in CallSetValues (class=0x400ee220, current=0xbfffd310, 
>     request=0xbfffcff0, new=0x893f508, args=0xbfffd660, num_args=2)
>     at SetValues.c:122
> #6  0x401e1ff6 in XtSetValues (w=0x893f508, args=0xbfffd660, num_args=2)
>     at SetValues.c:258
> #7  0x400a6bed in XawCommandToggle (w=0x893f508) at Command.c:320
> #8  0x400a6c1a in Set (w=0x893f508, event=0xbfffd920, params=0x0, 
>     num_params=0x402048e4) at Command.c:332
> #9  0x401f3c96 in HandleActions (w=0x893f508, event=0xbfffd920, 
>     stateTree=0x88e5838, accelWidget=0x0, procs=0x893f074, actions=0x402048dc)
>     at TMstate.c:632
> #10 0x401f42fd in HandleSimpleState (w=0x893f508, tmRecPtr=0x893f538, 
>     curEventPtr=0xbfffd780) at TMstate.c:870
> #11 0x401f49ae in _XtTranslateEvent (w=0x893f508, event=0xbfffd920)
>     at TMstate.c:1088
> #12 0x401c8b2e in XtDispatchEventToWidget (widget=0x893f508, event=0xbfffd920)
>     at Event.c:980
> #13 0x401c96de in _XtDefaultDispatcher (event=0xbfffd920) at Event.c:1441
> #14 0x401c990e in XtDispatchEvent (event=0xbfffd920) at Event.c:1497
> #15 0x401d743c in XtAppProcessEvent (app=0x84570f0, mask=1) at NextEvent.c:1407
> #16 0x082b0f6c in emacs_Xt_drain_queue ()
> 
> And, in fact, if I keep typing continue, I keep hitting that same
> watchpoint quite a large number of times.  It looks like most of them
> are in the guts of malloc, as it is moving blocks around, though.
> 
> What else can I do to help debug this?

The fact that XtReleaseGC() goes on to call XFreeGC() indicates that
the reference count has reached zero. However, the subsequent BadGC
errors indicate that something is still referencing it. This implies
that something is calling XtReleaseGC() for that GC when it shouldn't.

The "something" could be either Athena itself, one of the Lucid
widgets, or other code which allocates shared GCs (the only such case
which I can find in 21.4.15 is in toolbar-x.c; I don't have the 21.5
code; grep for XtReleaseGC).

Probably the most fruitful way to track this down is to nullify any GC
references when releasing a GC, so that attempts to re-release a GC
(e.g. due to reentry into a destructor) cause a segfault. toolbar-x.c
already does this (it sets them to (GC)-1), but the lwlib destructors
don't.

-- 
Glynn Clements <glynn.clements at virgin.net>