Thomas Achmann <achmann(a)aiss.com> wrote (originally, in xemacs-patches):
#8 0xdfb1918a in CleanupOnDisplayClose () from
/usr/dt/lib/libXm.so.3
#9 0xdf97d2a8 in XtCallCallbackList () from /usr/openwin/lib/libXt.so.4
#10 0xdf9837db in Phase2Callbacks () from /usr/openwin/lib/libXt.so.4
#11 0xdf983707 in Recursive () from /usr/openwin/lib/libXt.so.4
#12 0xdf983b43 in XtPhase2Destroy () from /usr/openwin/lib/libXt.so.4
#13 0xdf983caf in _XtDoPhase2Destroy () from /usr/openwin/lib/libXt.so.4
#14 0xdf983e1b in XtDestroyWidget () from /usr/openwin/lib/libXt.so.4
#15 0x081808fd in x_delete_device (d=0x846fe00) at device-x.c:875
FYI,
Any time the crash occurs in x_delete_device() ...
CleanupOnDisplayClose(), this is an indication of the "Motif progress
widget" bug. I don't know if this is an XEmacs or a Motif bug, but I'm
starting to think that this is a Motif bug. What seems to be happening
is that RemoveMatchingEntries() is freeing a block of memory, and then
DestroyImageCacheEntry() is referencing the freed block.
[ What's really strange is that I can't find any reference to
RemoveMatchingEntries() in any of my Motif sources. This bug occurs
on more than one platform, and so RemoveMatchingEntries() is not some
vendor-specific optimization. ]
The workaround appears to be to disable the Motif progress widget,
and go back to the old minibuffer-text-based progress indicator, by
placing the following into ~/.xemacs/init.el:
(setq progress-feedback-use-echo-area t)
--
Darryl Okahata
darrylo(a)soco.agilent.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.