6:24 p.m.
OK.. I originally thought this was some sort of AIX screwage.
It's been there since at least 21.2-b19 (I have a stack traceback from
Oct 29, 1999), but I've been seeing it under latest-CVS updated this morning
to -b46 plus. This on a RedHat 7.0 system.
Symptom: Using gnuclient, when you hit control-X # to close a client,
XEmacs folds up. Seems to be intermittent - today it's every 1-3 attempts,
but sometimes it won't bite for several days. Given that I'm seeing it
a lot, but it doesn't *seem* to be a show-stopper for others, I'm obviously
using some variant config that tickles the bug.
I've appended the Installation and tracebacks - anybody got any ideas?
/Valdis
8:20 p.m.
Valdis.Kletnieks(a)vt.edu wrote:
Symptom: Using gnuclient, when you hit control-X # to close a
client,
XEmacs folds up. Seems to be intermittent - today it's every 1-3 attempts,
but sometimes it won't bite for several days. Given that I'm seeing it
a lot, but it doesn't *seem* to be a show-stopper for others, I'm obviously
using some variant config that tickles the bug.
I've appended the Installation and tracebacks - anybody got any ideas?
Using Lucid menubars.
Using Lucid scrollbars.
Using Athena dialog boxes.
Using Athena native widgets.
Compiling in support for XIM (X11R5+ I18N input method).
- Using Motif to provide XIM support.
This (Motif for XIM but nothing else) looks like an odd combination.
#0 0x402eaf20 in XtIsSubclass () at eval.c:41
#1 0x402ebe35 in XtDisplayOfObject () at eval.c:41
#2 0x40132a14 in unset_current_xic () at eval.c:41
#3 0x40130375 in _XmImFreeShellData () at eval.c:41
This only serves to increase my suspicions about Motif's possible
involvement.
0x40022000 0x401bf5c8 Yes /usr/X11R6/lib/libXm.so.2
OpenMotif?
FWIW, I'm using OpenMotif, but:
Using Lucid menubars.
Using Lucid scrollbars.
Using Motif dialog boxes.
Using Motif native widgets.
Also, I have gnuserv use the currently selected frame rather than
opening a new one.
However, I've just run a quick test (with gnuserv using a separate
frame), and I get a similar crash:
#0 XtIsSubclass (widget=0x87a89d8, widgetClass=0x402d3f60) at Intrinsic.c:88
#1 0x402aafc2 in XtDisplayOfObject (object=0x87a89d8) at Intrinsic.c:685
#2 0x4014a998 in XmImVaSetValues () from /usr/X11R6/lib/libXm.so.2
#3 0x40148061 in _XmImFreeShellData () from /usr/X11R6/lib/libXm.so.2
#4 0x40150c5c in _XmRemoveGrab () from /usr/X11R6/lib/libXm.so.2
#5 0x402a0502 in Phase2Destroy (widget=0x87a16c8) at Destroy.c:154
print *widget
$1 = {core = {self = 0x87c1268, widget_class =
0x405bde88, parent = 0x86f3698,
xrm_name = 1337, being_destroyed = 1 '\001',
destroy_callbacks = 0x87bf498, constraints = 0x0, x = 0, y = 26,
width = 1186, height = 1009, border_width = 0, managed = 1 '\001',
sensitive = 1 '\001', ancestor_sensitive = 1 '\001',
event_table = 0x87c1148, tm = {translations = 0x0, proc_table = 0x87bf4f0,
current_state = 0x0, lastEventTime = 0}, accelerators = 0x0,
border_pixel = 0, border_pixmap = 2, popup_list = 0x0, num_popups = 0,
name = 0x86a9810 "emacs", screen = 0x86535d8, colormap = 32,
window = 14680201, depth = 16, background_pixel = 52857,
background_pixmap = 2, visible = 1 '\001', mapped_when_managed = 1
'\001'}}
OK; this looks valid enough (note: 'name = ... "emacs"'). However:
print *widget->core.widget_class
$2 = {core_class =
{superclass = 0x87d4580,
class_name = 0x87d4580 " 9}\bA\001", widget_size = 142248400,
class_initialize = 0x87c1268, class_part_initialize = 0x87b6898,
class_inited = 152 '\230', initialize = 0x878c1c0,
initialize_hook = 0x87bd550, realize = 0x874a508, actions = 0x870a558,
num_actions = 142119760, resources = 0x8789350,
num_resources = 1079762608, xrm_class = 1079762608,
compress_motion = -56 'È', compress_exposure = 220 'Ü',
compress_enterleave = 113 'q', visible_interest = 8 '\b',
destroy = 0x8724720, resize = 0x405bdec0 <main_arena+384>,
expose = 0x405bdec0 <main_arena+384>,
set_values = 0x405bdec8 <main_arena+392>,
set_values_hook = 0x405bdec8 <main_arena+392>,
set_values_almost = 0x87cdae0, get_values_hook = 0x878b6a0,
accept_focus = 0x86e5c80, version = 142378608,
callback_private = 0x405bdee0,
tm_table = 0x405bdee0
"\200\\n\bp\206|\bàÞ[＠àÞ[＠èÞ[＠èÞ[＠ðÞ[＠ðÞ[＠øÞ[＠øÞ[＠\2107}\b\2107}\b\bß[＠\bß[＠\020ß[＠\020ß[＠\030ß[＠\030ß[＠
ß[＠ ß[＠(ß[＠(ß[＠0ß[＠0ß[＠8ß[＠8ß[＠8â|\bÈ\"}\b8Å|\b\020ò|\bPß[＠Pß[＠Hè{\b\200o|\b",
query_geometry = 0x405bdee8 <main_arena+424>,
display_accelerator = 0x405bdee8 <main_arena+424>, extension = 0x405bdef0}}
This looks like complete garbage.
--
Glynn Clements <glynn(a)sensei.co.uk>
9:04 p.m.
New subject: Argh. Why is this happening to me?
On Mon, 26 Mar 2001 20:20:18 +0100, Glynn Clements said:
> Compiling in support for XIM (X11R5+ I18N input method).
> - Using Motif to provide XIM support.
This (Motif for XIM but nothing else) looks like an odd combination.
Blame configure. ;) It found the Motif libs, so it used them...
OpenMotif?
OpenMotif 2.1.30-6 RPMs on the RedHat box, Motif 2.1 on the AIX box that
gets hit by the problem as well.
Additional info:
./configure --with-widgets=no --with-dialogs=no --debug=no --error-checking=none
--with-mule=yes '--cflags=-Wall -Winline -Wmissing-prototypes -Wmissing-declara
tions -Wno-switch -Wpointer-arith -Wno-sign-compare -Wno-uninitialized -Wshadow
-g -pipe -s'
will survive at most 3 invocations of 'gnuclient /etc/motd' (and usually
crashes on trying to leave the first try). Using --with-mule=no produced
an xemacs that survived 14 invocations before I got bored. I've now cycled
through alternate builds with mule=no and mule=yes 3 times, and it seems to
only crash on Mule builds.
Diagnosis: Motif and MULE don't get along. I'm not sure what level of
show-stopper it is - I may be the only bozo trying to build with both
Mule and Motif.
More additional info: --with=mule=yes --with-xim=xlib and Athena
widgets/dialogs works as well. Seems like the instant you allow Motif
to be linked in for *anything* (even XIM) it breaks Mule.
I've now exhausted my debugging ability on THIS one. Has *anybody* actually
had a working build with both Mule and Motif at same time?
/Valdis
10:12 p.m.
New subject: Argh. Why is this happening to me?
Valdis.Kletnieks(a)vt.edu wrote:
Blame configure. ;) It found the Motif libs, so it used them...
That's reasonable. The help says:
--with-xim=xlib Compile with support for X input methods,
--with-xim=motif (*) Used in conjunction with Mule support.
Use either raw Xlib to provide XIM support, or
the Motif XmIm* routines (when available).
NOTE: On some systems bugs in X11's XIM support
will cause XEmacs to crash, so by default,
no XIM support is compiled in, unless running
on Solaris and the XmIm* routines are detected.
That clearly isn't true. I certainly didn't ask for XIM, but got it
anyhow. If anything, "xlib" should be the default.
> OpenMotif?
OpenMotif 2.1.30-6 RPMs on the RedHat box, Motif 2.1 on the AIX box that
gets hit by the problem as well.
Additional info:
./configure --with-widgets=no --with-dialogs=no --debug=no --error-checking=none
--with-mule=yes '--cflags=-Wall -Winline -Wmissing-prototypes -Wmissing-declara
tions -Wno-switch -Wpointer-arith -Wno-sign-compare -Wno-uninitialized -Wshadow
-g -pipe -s'
will survive at most 3 invocations of 'gnuclient /etc/motd' (and usually
crashes on trying to leave the first try). Using --with-mule=no produced
an xemacs that survived 14 invocations before I got bored. I've now cycled
through alternate builds with mule=no and mule=yes 3 times, and it seems to
only crash on Mule builds.
Note: this doesn't seem to be specific to gnuserv; for me, "C-x 5 2"
then "C-x 5 0" causes instant segfault, with the familiar backtrace.
Diagnosis: Motif and MULE don't get along. I'm not sure
what level of
show-stopper it is - I may be the only bozo trying to build with both
Mule and Motif.
Nope; although I only use one frame, so I never noticed it until I
actually went looking.
More additional info: --with=mule=yes --with-xim=xlib and Athena
widgets/dialogs works as well. Seems like the instant you allow Motif
to be linked in for *anything* (even XIM) it breaks Mule.
What about if you use Motif for everything *except* XIM?
I'm wondering if this has anything to do with the "VendorShell"
wierdness? This is one aspect of Xt I truly never got a handle on.
Both libXaw and libXm define vendorShellClassRec and
vendorShellWidgetClass. Past experience suggests that linking against
both can have odd consequences; the order in which the libraries are
specified in the link command can have an effect.
--
Glynn Clements <glynn(a)sensei.co.uk>
2:52 a.m.
New subject: Argh. Why is this happening to me?
Valdis> Diagnosis: Motif and MULE don't get along. I'm not sure what
level of
Valdis> show-stopper it is - I may be the only bozo trying to build with both
Valdis> Mule and Motif.
I tried and gave up. I had Motif trouble on both Solaris 7 (without
Mule) and Linux (with and without Mule, openmotif). Perhaps when
gtk-xemacs is stable enough the Motif support could be pulled entirely?
Isaac
4:16 a.m.
New subject: Argh. Why is this happening to me?
Isaac Hollander wrote:
Valdis> Diagnosis: Motif and MULE don't get along.
I'm not sure what level of
Valdis> show-stopper it is - I may be the only bozo trying to build with both
Valdis> Mule and Motif.
I tried and gave up. I had Motif trouble on both Solaris 7 (without
Mule) and Linux (with and without Mule, openmotif). Perhaps when
gtk-xemacs is stable enough the Motif support could be pulled entirely?
If we support Lucid and Athena, then supporting yet another Xt-based
widget set (i.e. Motif) isn't that much work. And I doubt if Xt
support is likely to be going any time soon (does GTK support multiple
displays yet?)
--
Glynn Clements <glynn(a)sensei.co.uk>
8437
days inactive
8438
days old
5 comments
3 participants
participants (3)
-
Glynn Clements -
Isaac Hollander -
Valdis Kl=?iso8859-4?Q?=BA?=tnieks