10:11 a.m.
Hi,
somehow xemacs 21.4.4 crashed.
All I did is to start xemacs with a file:
xemacs .xemacs/init.el
and then opened the file-menue and exited xemacs.
ragards
thomas
==================================
gdb /usr/local/gnu/xemacs-21.4.4/bin/xemacs core
(gdb) bt
#0 0xdf6d66ac in _libc_kill () from /usr/lib/libc.so.1
#1 0xdf6d608c in kill () from /usr/lib/libc.so.1
#2 0x080c329f in fatal_error_signal (sig=11) at emacs.c:535
#3 0xdf689f59 in sigacthandler () from /usr/lib/libc.so.1
#4 <signal handler called>
#5 0xdfb1906a in RemoveMatchingEntries () from /usr/dt/lib/libXm.so.3
#6 0xdfb190f5 in RemoveDisplayPixmaps () from /usr/dt/lib/libXm.so.3
#7 0xdfada7bd in _XmEnumerateHashTable () from /usr/dt/lib/libXm.so.3
#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
#16 0x080b74ec in delete_device_internal (d=0x846fe00, force=1,
called_from_delete_console=1, from_io_error=0) at device.c:823
#17 0x080b02ea in delete_console_internal (con=0x8434300, force=1,
called_from_kill_emacs=1, from_io_error=0) at console.c:689
#18 0x080c4ad6 in Fkill_emacs (arg=136566788) at emacs.c:2848
#19 0x080ca4a7 in Ffuncall (nargs=1, args=0x8046724) at eval.c:3528
#20 0x080a6d1f in execute_optimized_program (
program=0x85bbe90 "Ä\bÅ\"\210ÅÆÇÈ \"s«\006ÉÊ!?ËÌ!«3Ì Í\032\211\e«
Î\013＠!Ïs«\022Ð\013＠!\031Ð\013＠\t\"\210\t)«\003Å\022\013A\211\023¬â\n?®\005\212Ñ\213)*\bÒÓ!\003Ô
\207]", stack_depth=5, constants_data=0x83c7a10) at bytecode.c:746
#21 0x080a6a37 in funcall_compiled_function (fun=138217756, nargs=1,
args=0x8046874) at bytecode.c:515
#22 0x080ca64b in Ffuncall (nargs=2, args=0x8046870) at eval.c:3563
#23 0x080aa9d7 in Fcall_interactively (function=136658388,
record_flag=136566788, keys=136566788) at callint.c:940
#24 0x080ca4c9 in Ffuncall (nargs=2, args=0x8046a74) at eval.c:3528
#25 0x080cf296 in call1 (fn=136643380, arg0=136658388) at eval.c:4183
#26 0x080f1d93 in execute_command_event (command_builder=0x838abc0,
event=139650072) at event-stream.c:3910
#27 0x080f241f in Fdispatch_event (event=139650072) at
event-stream.c:4247
#28 0x080aeb0c in Fcommand_loop_1 () at cmdloop.c:583
#29 0x080aed6d in command_loop_1 (dummy=136566788) at cmdloop.c:494
#30 0x080cfd76 in condition_case_1 (handlers=136566884,
bfun=0x80aed54 <command_loop_1>, barg=136566788,
hfun=0x80aeddc <cmd_error>, harg=136566788) at eval.c:1651
#31 0x080aeecb in command_loop_2 (dummy=136566788) at cmdloop.c:256
#32 0x080cfc48 in internal_catch (tag=136646828,
func=0x80aee90 <command_loop_2>, arg=136566788, threw=0x0) at
eval.c:1317
#33 0x080ae856 in initial_command_loop (load_me=136566788) at
cmdloop.c:305
#34 0x080c4410 in sort_args (argc=2, argv=0x8047170) at emacs.c:2344
#35 0x080c5f75 in main ()
#36 0x0809a8cf in _start ()
=================
Lisp backtrace follows:
kill-emacs()
# bind (arg)
save-buffers-kill-emacs(nil)
# bind (command-debug-status)
call-interactively(save-buffers-kill-emacs)
# (condition-case ... . error)
# (catch top-level ...)
Segmentation Fault
=======================================
M-x discribe-installation:
uname -a: SunOS xxxx.xxx.de 5.6 Generic_105182-09 i86pc i386 i86pc
./configure '--with-site-lisp=no' '--with-site-modules=no'
'--with-png'
'--ldflags=-L/usr/local/lib' '--prefix=/usr/local/gnu/xemacs-21.4.4'
'--site-prefixes=/users/cvm/local/opt/xpm/' '--compiler=gcc-2.95.2'
'--with-workshop'
XEmacs 21.4.4 "Artificial Intelligence" configured for
`i386-pc-solaris2.6'.
Compilation / Installation:
Source code location:
/xxx/src.SunOS-i386-5.6/xemacs/xemacs-21.4.4
Installation prefix: /usr/local/gnu/xemacs-21.4.4
Additional prefixes: /users/xxxx/local/opt/xpm/
Runtime library search path: /usr/dt/lib:/usr/openwin/lib
Operating system description file: `s/sol2.h'
Machine description file: `m/intel386.h'
Compiler: gcc-2.95.2 -g -O3 -Wall -Wno-switch
-Winline -Wmissing-prototypes -Wshadow -Wsign-compare -Wpointer-arith
Relocating allocator for buffers: yes
GNU version of malloc: yes
Window System:
Compiling in support for the X window system:
- X Windows headers location: /usr/dt/include
/usr/openwin/include
- X Windows libraries location: /usr/dt/lib
/usr/openwin/lib
- Handling WM_COMMAND properly.
Using Lucid menubars.
Using Lucid scrollbars.
Using Motif dialog boxes.
Using Motif native widgets.
TTY:
Images:
Compiling in support for GIF images (builtin).
Compiling in support for XPM images.
Compiling in support for PNG images.
Sound:
Compiling in support for sound (native).
Databases:
Compiling in support for DBM.
Internationalization:
Mail:
Compiling in support for "dot-locking" mail spool file locking method.
Other Features:
Compiling in support for ToolTalk.
Compiling in support for Sun WorkShop.
Compiling in support for dynamic shared object modules.
--
--------------------------------------------
Thomas Achmann achmann(a)aiss.com
PDF GmbH, aiss Division
Bayerstr. 115, D-80335 Munich, Germany
Tel: +49-89-767062-26, Fax: +49-89-767062-11
--------------------------------------------
5:58 p.m.
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.
6:56 p.m.
At 09:58 AM 10/30/01 -0800, Darryl Okahata wrote:
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)
Hey Darryl,
It would be great if you could think of any work-around. Does purify reveal
anything. The bug has been around for ever and it would be really nice to
solve it somehow.
andy
8:20 p.m.
Andy Piper <andyp(a)bea.com> wrote:
It would be great if you could think of any work-around.
Unfortunately, "(setq progress-feedback-use-echo-area t)" is the
only workaround that I can determine. ;-(
Does purify reveal
anything. The bug has been around for ever and it would be really nice to
solve it somehow.
Unfortunately, purify is the one that's saying that Motif is
freeing the memory, and that Motif is then accessing the free()'d
memory. Unless XEmacs is improperly using the progress widget, I'd lean
towards the idea that this is a Motif bug.
[ Furthermore, I'm doing all this on an old HP-UX workstation, and
compiling openmotif (for testing purposes) is a real pain on the
(ancient) OS that I'm still using. Yeah, I need to upgrade, but we're
under the horribly tight expense controls that afflict the entire
industry. ]
[ P.S. -- The netinstaller seems to be working well, and I've managed to
download everything to a local disk. Good work. ]
--
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.
8:17 p.m.
At 12:20 PM 10/30/01 -0800, Darryl Okahata wrote:
Unfortunately, purify is the one that's saying that Motif
is
freeing the memory, and that Motif is then accessing the free()'d
memory. Unless XEmacs is improperly using the progress widget, I'd lean
towards the idea that this is a Motif bug.
Right, but which Motif call. Maybe we could just not make the call - sure
we might get a leak but doesn't seem so bad for delete_device()
andy
9:20 p.m.
Andy Piper <andyp(a)bea.com> wrote:
Right, but which Motif call. Maybe we could just not make the call -
sure
we might get a leak but doesn't seem so bad for delete_device()
I'm not sure it's that simple, as the "offending function" is
XtDestroyWidget(). I've attached a purify fragment that describes
what's happening. Two things to note, though:
1. Purify stack traces are inverted. Most-recently-called functions are
at the top.
2. This is for XEmacs 21.4.4. Line numbers might be occasionally off,
as I was trying to tweak the code to further characterize this bug.
Basically, all of the problems are being caused by internal Motif code,
deep in the bowels.
--
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.
3:46 p.m.
[sorry to resurrect this, but I have some more info]
Darryl Okahata writes:
Andy Piper <andyp(a)bea.com> wrote:
> Right, but which Motif call. Maybe we could just not make the call - sure
> we might get a leak but doesn't seem so bad for delete_device()
I'm not sure it's that simple, as the "offending function" is
XtDestroyWidget(). I've attached a purify fragment that describes
what's happening. Two things to note, though:
1. Purify stack traces are inverted. Most-recently-called functions are
at the top.
2. This is for XEmacs 21.4.4. Line numbers might be occasionally off,
as I was trying to tweak the code to further characterize this bug.
Basically, all of the problems are being caused by internal Motif code,
deep in the bowels.
I'm also seeing this, but I'm not using the graphical progress
widget. What I do is:
C-x C-f ~/test.c
(make-frame-on-display "rpluim-1:0") [this is physically a different
machine and screen]
C-x C-c [on the new frame. doing it on the old frame works fine]
This gives:
#0 0xfec9a118 in _libc_kill () from /usr/lib/libc.so.1
#1 0x77f48 in fatal_error_signal (sig=11)
at /codes/rpluim/xemacs-21.4/src/emacs.c:539
#2 <signal handler called>
#3 0xfee929f4 in XFindContext () from /usr/openwin/lib/libX11.so.4
#4 0xfee92930 in XFindContext () from /usr/openwin/lib/libX11.so.4
#5 0xff297e54 in DisplayDestroy () from /usr/dt/lib/libXm.so.4
#6 0xfefbece0 in XtCallCallbackList () from /usr/openwin/lib/libXt.so.4
#7 0xfefc486c in XtPhase2Destroy () from /usr/openwin/lib/libXt.so.4
#8 0xfefc45d0 in _XtDoPhase2Destroy () from /usr/openwin/lib/libXt.so.4
#9 0xfefc43b4 in XtDestroyWidget () from /usr/openwin/lib/libXt.so.4
#10 0x15cf9c in x_delete_device (d=0x523f00)
This is on Solaris 2.7, using 21.4.5. I'm going to download OpenMotif
and see if that helps, since this points more towards Motif than
XEmacs.
Robert
--
1:29 p.m.
Robert Pluim writes:
This is on Solaris 2.7, using 21.4.5. I'm going to download OpenMotif
and see if that helps, since this points more towards Motif than
XEmacs.
And just to confirm that this is in fact a Motif bug, installing the
following patches on my 2.7 machine solved the problem for me:
107081-40 107656-07
Tthe equivalent patches for Solaris 2.8 are: 108940-33 and 108652-25.
--
5:05 p.m.
Can we put this in PROBLEMS?
andy
At 02:29 PM 11/21/01 +0100, Robert Pluim wrote:
Robert Pluim writes:
>
> This is on Solaris 2.7, using 21.4.5. I'm going to download OpenMotif
> and see if that helps, since this points more towards Motif than
> XEmacs.
And just to confirm that this is in fact a Motif bug, installing the
following patches on my 2.7 machine solved the problem for me:
107081-40 107656-07
Tthe equivalent patches for Solaris 2.8 are: 108940-33 and 108652-25.
--
6 p.m.
New subject: xcscope in XEmacs
I just installed the Debian version of Emacs 21.1 and played around
with the gud mode. I noticed that for C files I got an extra menu
called Cscope, that gave access to csope based on Darryl's
xcscope.el.
As they say, this looks like one of the best things since sliced bread
and I would really like to see it included in an XEmacs package.
Maybe prog-modes would be appropriate or alternatively a new package?
Darryl, do you have any plans to add it?
Gunnar
7 p.m.
New subject: xcscope in XEmacs
Gunnar Evermann <ge204(a)eng.cam.ac.uk> wrote:
I just installed the Debian version of Emacs 21.1 and played around
with the gud mode. I noticed that for C files I got an extra menu
called Cscope, that gave access to csope based on Darryl's
xcscope.el.
Eeep. I hadn't realized that it's spread that far.
As they say, this looks like one of the best things since sliced
bread
and I would really like to see it included in an XEmacs package.
Maybe prog-modes would be appropriate or alternatively a new package?
Darryl, do you have any plans to add it?
I've been meaning to ask if people want it added, but, as usual,
I haven't had the time. If the XEmacs-review cabal will bless it, I can
add it to prog-modes.
--
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.
6:09 a.m.
New subject: xcscope in XEmacs
|--==> "DO" == Darryl Okahata <darrylo(a)soco.agilent.com> writes:
DO> Gunnar Evermann <ge204(a)eng.cam.ac.uk> wrote:
>As they say, this looks like one of the best things since sliced
bread
If it has Gunnar's "best thing since sliced bread" seal of approval,
that's good enough for me. :-)
DO> I've been meaning to ask if people want it added, but, as usual,
DO> I haven't had the time. If the XEmacs-review cabal will bless it, I can
DO> add it to prog-modes.
Consider it blessed. You've got CVS commit access don't you Darryl?
Please add xcscope to prog-modes.
It won't make it into to this SUMO (which I'm uploading as I type
this), but I'll release a new prog-modes package next week.
Give me a yell if you run into problems, Darryl.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
7:50 p.m.
This does look like a Motif bug. The pixmaps aren't even our own in this
instance.
andy
-----Original Message-----
From: xemacs-beta-admin(a)xemacs.org
[mailto:xemacs-beta-admin＠xemacs.org]On Behalf Of Darryl Okahata
Sent: Tuesday, October 30, 2001 1:20 PM
To: Andy Piper
Cc: xemacs-beta(a)xemacs.org
Subject: Re: Crash with xemacs 21.4.4
Andy Piper <andyp(a)bea.com> wrote:
> Right, but which Motif call. Maybe we could just not make the
call - sure
> we might get a leak but doesn't seem so bad for delete_device()
I'm not sure it's that simple, as the "offending function" is
XtDestroyWidget(). I've attached a purify fragment that describes
what's happening. Two things to note, though:
1. Purify stack traces are inverted. Most-recently-called functions are
at the top.
2. This is for XEmacs 21.4.4. Line numbers might be occasionally off,
as I was trying to tweak the code to further characterize this bug.
Basically, all of the problems are being caused by internal Motif code,
deep in the bowels.
--
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.
8170
days inactive
8220
days old
12 comments
7 participants
participants (7)
-
Andy Piper -
Andy Piper -
Darryl Okahata -
Gunnar Evermann -
Robert Pluim -
Steve Youngs -
Thomas Achmann