7:16 p.m.
Clicking anywhere on the menu bar causes xemacs to crash with the
following terminal output:
Fatal error: assertion failed, file menubar-x.c, line 579, ABORT()
Fatal error (6).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.
Your version of XEmacs was distributed with a PROBLEMS file that may
describe your crash, and with luck a workaround. Please check it first,
but do report the crash anyway.
Please report this bug by invoking M-x report-emacs-bug, or by selecting
`Send Bug Report' from the Help menu. If that won't work, send ordinary
email to `xemacs-beta(a)xemacs.org'. *MAKE SURE* to include this entire
output from this crash, especially including the Lisp backtrace, as well
as the XEmacs configuration from M-x describe-installation (or
equivalently, the file `Installation' in the top of the build
tree).
*Please* try *hard* to obtain a C stack backtrace; without it, we are
unlikely
to be able to analyze the problem. Locate the core file produced as a
result
of this crash (often called `core' or `core.<process-id>', and located
in
the directory in which you started XEmacs or your home directory), and
type
gdb /usr/bin/xemacs core
then type `where' at the debugger prompt. No GDB on your system? You
may
have DBX, or XDB, or SDB. (Ask your system administrator if you need
help.)
If no core file was produced, enable them (often with `ulimit -c
unlimited')
in case of future recurrance of the
crash.
Lisp backtrace follows:
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
# bind (inhibit-quit)
# (condition-case ... . error)
# (catch top-level ...)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:09 a.m.
Matthias Scheutz writes:
Clicking anywhere on the menu bar causes xemacs to crash with the
following terminal output:
Please start XEmacs, save the output of the M-x describe-installation
command to a file, and send it to us. We need both version and
configuration information.
If you can replicate the crash, please do
$ gdb /usr/bin/xemacs 2>&1 | tee gdb.log
(gdb) run
# make XEmacs crash
(gdb) bt
(gdb) quit
$
and send us the output. Since it's in /usr/bin, you probably should
report the bug to your OS distribution, unless you have compiled it
yourself and installed it to /usr/bin anyway.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
1:07 p.m.
[?1034hGNU gdb (GDB) Fedora (6.8.50.20090302-38.fc11)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "i586-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Missing separate debuginfos, use: debuginfo-install
xemacs-21.5.28-12.fc11.i586 xemacs-nox-21.5.28-12.fc11.i586
(gdb) run
Starting program: /usr/bin/xemacs
[Thread debugging using libthread_db enabled]
Warning: Missing charsets in String to FontSet conversion
Detaching after fork from child process 12291.
Detaching after fork from child process 12292.
Detaching after fork from child process 12293.
Detaching after fork from child process 12296.
Detaching after fork from child process 12297.
Detaching after fork from child process 12298.
Fatal error: assertion failed, file menubar-x.c, line 579, ABORT()
Program received signal SIGABRT, Aborted.
0x00277422 in __kernel_vsyscall ()
(gdb) bt
#0 0x00277422 in __kernel_vsyscall ()
#1 0x007087c1 in raise () from /lib/libc.so.6
#2 0x0070a092 in abort () from /lib/libc.so.6
#3 0x080c1e3b in really_abort ()
#4 0x080c2e23 in assert_failed ()
#5 0x081f7a07 in ?? ()
#6 0x081f7d19 in ?? ()
#7 0x05d0e24c in XtCallCallbackList () from /usr/lib/libXt.so.6
#8 0x0820d0c1 in ?? ()
#9 0x05d4682b in ?? () from /usr/lib/libXt.so.6
#10 0x05d46978 in ?? () from /usr/lib/libXt.so.6
#11 0x05d47268 in _XtTranslateEvent () from /usr/lib/libXt.so.6
#12 0x05d1cc12 in XtDispatchEventToWidget () from /usr/lib/libXt.so.6
#13 0x05d1d46b in ?? () from /usr/lib/libXt.so.6
#14 0x05d1c2bd in XtDispatchEvent () from /usr/lib/libXt.so.6
#15 0x05d29f25 in XtAppProcessEvent () from /usr/lib/libXt.so.6
#16 0x081dbae0 in ?? ()
#17 0x080d9aa5 in ?? ()
#18 0x080db03f in Fnext_event ()
#19 0x080da7af in Fnext_command_event ()
#20 0x080c92dd in Ffuncall ()
#21 0x0809baa7 in execute_optimized_program ()
#22 0x0809be64 in Fbyte_code ()
#23 0x080cf2be in Feval ()
#24 0x080c8be1 in internal_catch ()
#25 0x0809a703 in execute_rare_opcode ()
#26 0x0809bc83 in execute_optimized_program ()
#27 0x080c93c8 in Ffuncall ()
#28 0x0809baa7 in execute_optimized_program ()
#29 0x080ced44 in Feval ()
#30 0x080cae8a in condition_case_1 ()
#31 0x080cde3f in condition_case_3 ()
#32 0x0809a6a4 in execute_rare_opcode ()
#33 0x0809bc83 in execute_optimized_program ()
#34 0x080ced44 in Feval ()
#35 0x080cae8a in condition_case_1 ()
#36 0x080a4bfa in ?? ()
#37 0x080c8be1 in internal_catch ()
#38 0x080a4b1d in initial_command_loop ()
#39 0x080c4804 in xemacs_21_5_b28_i386_redhat_linux ()
#40 0x080c540c in main ()
(gdb) quit
The program is running. Quit anyway (and kill it)? (y or n)
On Mon, 2009-08-31 at 12:09 +0900, Stephen J. Turnbull wrote:
Matthias Scheutz writes:
> Clicking anywhere on the menu bar causes xemacs to crash with the
> following terminal output:
Please start XEmacs, save the output of the M-x describe-installation
command to a file, and send it to us. We need both version and
configuration information.
If you can replicate the crash, please do
$ gdb /usr/bin/xemacs 2>&1 | tee gdb.log
(gdb) run
# make XEmacs crash
(gdb) bt
(gdb) quit
$
and send us the output. Since it's in /usr/bin, you probably should
report the bug to your OS distribution, unless you have compiled it
yourself and installed it to /usr/bin anyway.
--
Matthias Scheutz, Ph.D. Ph.D. http://mypage.iu.edu/~mscheutz/
------------------------------------------------------------------------
Associate Professor Cognitive Science, Computer Science and Informatics
Adjunct Associate Professor Psychological and Brain Sciences
Director Human-Robot Interaction Laboratory
Cognitive Science Program Indiana University Bloomington
841 Eigenmann Hall, 1910 E 10th St. Phone: +1 (812) 856-1178
Bloomington, IN 47406-7512, USA Fax: +1 (812) 855-1086
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6:31 p.m.
On Sun, Aug 30, 2009 at 9:09 PM, Stephen J. Turnbull<stephen(a)xemacs.org> wrote:
and send us the output. Since it's in /usr/bin, you probably
should
report the bug to your OS distribution, unless you have compiled it
yourself and installed it to /usr/bin anyway.
That would be Fedora, which means I'm handling it. See
https://bugzilla.redhat.com/show_bug.cgi?id=520248 if you want to
follow along.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
9:42 p.m.
On Mon, Aug 31, 2009 at 11:31 AM, Jerry James<james(a)xemacs.org> wrote:
That would be Fedora, which means I'm handling it. See
https://bugzilla.redhat.com/show_bug.cgi?id=520248 if you want to
follow along.
I may not have a chance to keep debugging this for a few hours. In
the meantime, I've got a reproducer that works reliably for me:
1. xemacs --vanilla
2. In *scratch* evaluate: (load "mule-util")
3. Click on the menubar
That's a reliable crash for me.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
9:42 p.m.
Yup, that does the trick!
On Mon, 2009-08-31 at 14:42 -0600, Jerry James wrote:
On Mon, Aug 31, 2009 at 11:31 AM, Jerry James<james(a)xemacs.org>
wrote:
> That would be Fedora, which means I'm handling it. See
> https://bugzilla.redhat.com/show_bug.cgi?id=520248 if you want to
> follow along.
I may not have a chance to keep debugging this for a few hours. In
the meantime, I've got a reproducer that works reliably for me:
1. xemacs --vanilla
2. In *scratch* evaluate: (load "mule-util")
3. Click on the menubar
That's a reliable crash for me.
--
Matthias Scheutz, Ph.D. Ph.D. http://mypage.iu.edu/~mscheutz/
------------------------------------------------------------------------
Associate Professor Cognitive Science, Computer Science and Informatics
Adjunct Associate Professor Psychological and Brain Sciences
Director Human-Robot Interaction Laboratory
Cognitive Science Program Indiana University Bloomington
841 Eigenmann Hall, 1910 E 10th St. Phone: +1 (812) 856-1178
Bloomington, IN 47406-7512, USA Fax: +1 (812) 855-1086
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
9:50 p.m.
On Mon, Aug 31, 2009 at 2:42 PM, Jerry James<james(a)xemacs.org> wrote:
I may not have a chance to keep debugging this for a few hours. In
the meantime, I've got a reproducer that works reliably for me:
1. xemacs --vanilla
2. In *scratch* evaluate: (load "mule-util")
3. Click on the menubar
That's a reliable crash for me.
Okay, I lied. I had a few more minutes. Now I've got it down to this recipe:
1. xemacs --vanilla
2. M-x find-library mule-util
3. Evaluate (defun truncate-string-to-width ...) in that file.
4. Click on the menubar
So something is funny with the mule-util.el version of
truncate-string-to-width. Does anybody know why there are versions of
that function in both subr.el and mule-util.el? There are versions of
store-substring in both places, too.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:17 p.m.
Jerry James wrote:
Okay, I lied. I had a few more minutes. Now I've got it down to this recipe:
1. xemacs --vanilla
2. M-x find-library mule-util
3. Evaluate (defun truncate-string-to-width ...) in that file.
4. Click on the menubar
So something is funny with the mule-util.el version of
truncate-string-to-width. Does anybody know why there are versions of
that function in both subr.el and mule-util.el? There are versions of
store-substring in both places, too.
On Windows XP Pro SP3, I don't get a crash, but I do get:
(event/warning) Error during menu handling: (wrong-number-of-arguments
((lambda (str end-column &optional start-column padding) Truncate string
STR to end at column END-COLUMN.
The optional 2nd arg START-COLUMN, if non-nil, specifies
the starting column; that means to return the characters occupying
columns START-COLUMN ... END-COLUMN of STR.
The optional 3rd arg PADDING, if non-nil, specifies a padding character
to add at the end of the result if STR doesn't reach column END-COLUMN,
or if END-COLUMN comes in the middle of a character in STR.
PADDING is also added at the beginning of the result
if column START-COLUMN appears in the middle of a character in STR.
If PADDING is nil, no padding is added in these cases, so
the resulting string may be narrower than END-COLUMN. (or start-column
(setq start-column 0)) (let ((len (length str)) (idx 0) (column 0)
(head-padding ) (tail-padding ) ch last-column last-idx from-idx)
(condition-case nil (while (< column start-column) (setq ch (aref str
idx) column (+ column (char-width ch)) idx (1+ idx))) (args-out-of-range
(setq idx len))) (if (< column start-column) (if padding (make-string
end-column padding) ) (if (and padding (> column start-column)) (setq
head-padding (make-string (- column start-column) padding))) (setq
from-idx idx) (if (< end-column column) (setq idx from-idx)
(condition-case nil (while (< column end-column) (setq last-column
column last-idx idx ch (aref str idx) column (+ column (char-width ch))
idx (1+ idx))) (args-out-of-range (setq idx len))) (if (> column
end-column) (setq column last-column idx last-idx)) (if (and padding (<
column end-column)) (setq tail-padding (make-string (- end-column
column) padding)))) (setq str (substring str from-idx idx)) (if padding
(concat head-padding str tail-padding) str)))) 5))
Backtrace follows:
# bind (inhibit-quit padding start-column end-column str)
truncate-string-to-width("str))))" 40 nil nil t)
# (unwind-protect ...)
# (catch #<INTERNAL OBJECT (XEmacs bug?) (opaque, size=0) 0x17e3da8> ...)
# (unwind-protect ...)
# bind (inhibit-quit)
# (unwind-protect ...)
# (unwind-protect ...)
("next_event_internal()" "[internal]")
# (unwind-protect ...)
# bind (inhibit-quit)
(next-event "[internal]")
# (condition-case ... . error)
# (catch top-level ...)
Rodney
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:42 p.m.
On Mon, Aug 31, 2009 at 3:17 PM, Rodney Sparapani<rsparapa(a)mcw.edu> wrote:
On Windows XP Pro SP3, I don't get a crash, but I do get:
(event/warning) Error during menu handling: (wrong-number-of-arguments
((lambda (str end-column &optional start-column padding) Truncate string STR
to end at column END-COLUMN.
The optional 2nd arg START-COLUMN, if non-nil, specifies
the starting column; that means to return the characters occupying
columns START-COLUMN ... END-COLUMN of STR.
Ah ha! So the mule-util.el version of truncate-string-to-width is
lacking the 3rd optional argument, ellipses, of the version in
subr.el. Thanks, Rodney!
The ChangeLog seems to show that truncate-string-to-width was moved to
mule-util.el by MORIOKA Tomohiko on 24 Jun 1997. On 15 Mar 2002, Ben
Wing noticed that the function was missing from subr.el and "restored"
it. The latter version was modified to take the ellipses argument by
Ben Wing on 23 May 2002, and further modified by Ben up through 1 Mar
2003. Meanwhile, the original version was preserved in mule-util.el,
where it resides to this day.
Unless someone knows a reason why that history is incorrect, the right
thing to do here is to kill off the first 3 definitions in
mule-util.el. I'll whip up a patch to do that in a bit.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:01 a.m.
Jerry James writes:
Unless someone knows a reason why that history is incorrect, the
right
thing to do here is to kill off the first 3 definitions in
mule-util.el. I'll whip up a patch to do that in a bit.
Please do; that's the right thing to do. That doesn't mean we won't
get further problems in Mule, though. We should be prepared for
weirdness.
However, there's also the question of how Lisp code can crash at all.
Do you understand that mechanism?
Please take the minimal reproducer, add it to
tests/reproduce-crashes.el, and make sure it crashes there. Add an
XEmacs bug pointing to this thread and that test. Or I can do it, but
without a tracker entry my memory has been rather fallible of late.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5:43 p.m.
On Mon, Aug 31, 2009 at 9:01 PM, Stephen J. Turnbull<stephen(a)xemacs.org> wrote:
However, there's also the question of how Lisp code can crash at
all.
Do you understand that mechanism?
The missing argument to the mule-util version of
truncate-string-to-width causes compute_menubar_data to return NULL
somehow. I still don't understand what's going on there. Then we
trigger the ABORT on line 579 of menubar-x.c.
Please take the minimal reproducer, add it to
tests/reproduce-crashes.el, and make sure it crashes there. Add an
XEmacs bug pointing to this thread and that test. Or I can do it, but
without a tracker entry my memory has been rather fallible of late.
We don't have a minimal reproducer anymore, since I nuked the
offending version of truncate-string-to-width. I've tried to find
other ways to trigger this crash, so far without success. The only
way I know how to do it is to redefine truncate-string-to-width to the
mule-util version. Maybe it should be something like this (where I'm
using old-truncate-string-to-width to avoid affecting the other
tests)?
(defun old-truncate-string-to-width (str end-column &optional
start-column padding)
"Truncate string STR to end at column END-COLUMN.
The optional 2nd arg START-COLUMN, if non-nil, specifies
the starting column; that means to return the characters occupying
columns START-COLUMN ... END-COLUMN of STR.
The optional 3rd arg PADDING, if non-nil, specifies a padding character
to add at the end of the result if STR doesn't reach column END-COLUMN,
or if END-COLUMN comes in the middle of a character in STR.
PADDING is also added at the beginning of the result
if column START-COLUMN appears in the middle of a character in STR.
If PADDING is nil, no padding is added in these cases, so
the resulting string may be narrower than END-COLUMN."
(or start-column
(setq start-column 0))
(let ((len (length str))
(idx 0)
(column 0)
(head-padding "") (tail-padding "")
ch last-column last-idx from-idx)
(condition-case nil
(while (< column start-column)
(setq ch (aref str idx)
column (+ column (char-width ch))
idx (1+ idx)))
(args-out-of-range (setq idx len)))
(if (< column start-column)
(if padding (make-string end-column padding) "")
(if (and padding (> column start-column))
(setq head-padding (make-string (- column start-column) padding)))
(setq from-idx idx)
(if (< end-column column)
(setq idx from-idx)
(condition-case nil
(while (< column end-column)
(setq last-column column
last-idx idx
ch (aref str idx)
column (+ column (char-width ch))
idx (1+ idx)))
(args-out-of-range (setq idx len)))
(if (> column end-column)
(setq column last-column idx last-idx))
(if (and padding (< column end-column))
(setq tail-padding (make-string (- end-column column) padding))))
(setq str (substring str from-idx idx))
(if padding
(concat head-padding str tail-padding)
str))))
(defbug 12 current
"Crash when clicking on the menubar, triggered by a Lisp error due to a
version of truncate-string-to-width that does not take 5 parameters.
Fatal error: assertion failed, file menubar-x.c, line 579, ABORT()
Reported: https://bugzilla.redhat.com/show_bug.cgi?id=480845
<1251569781.4318.2.camel＠mslap>"
(fset 'truncate-string-to-width #'old-truncate-string-to-width)
(accelerate-menu))
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
9:55 p.m.
We don't have a minimal reproducer anymore, since I nuked the
offending version of truncate-string-to-width.
I have seen a similar crash on fedora 11.
To reproduce: xemacs -q
and then create a new frame: C-x 5 2
xemacs dies.
I'm not sure if this is the same thing though.
-Ram
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:08 p.m.
On Wed, Sep 2, 2009 at 2:55 PM, Ram Bhamidipaty<rambham(a)gmail.com> wrote:
I have seen a similar crash on fedora 11.
To reproduce: xemacs -q
and then create a new frame: C-x 5 2
xemacs dies.
I'm not sure if this is the same thing though.
-Ram
I've been using C-x 5 2 successfully on Fedora 11 for some time, so I
need more information to diagnose your crash. Can you
"debuginfo-install xemacs", run XEmacs in gdb, provoke the crash, and
get a backtrace? File a bug in bugzilla.redhat.com and I'll take a
look. Thanks,
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
2:40 a.m.
Bugzilla 520977 has been created.
-Ram
On Wed, Sep 2, 2009 at 3:08 PM, Jerry James<james(a)xemacs.org> wrote:
On Wed, Sep 2, 2009 at 2:55 PM, Ram
Bhamidipaty<rambham(a)gmail.com> wrote:
> I have seen a similar crash on fedora 11.
>
> To reproduce: xemacs -q
> and then create a new frame: C-x 5 2
>
> xemacs dies.
>
> I'm not sure if this is the same thing though.
>
> -Ram
I've been using C-x 5 2 successfully on Fedora 11 for some time, so I
need more information to diagnose your crash. Can you
"debuginfo-install xemacs", run XEmacs in gdb, provoke the crash, and
get a backtrace? File a bug in bugzilla.redhat.com and I'll take a
look. Thanks,
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
3:19 a.m.
On Wed, Sep 2, 2009 at 7:40 PM, Ram Bhamidipaty<rambham(a)gmail.com> wrote:
Bugzilla 520977 has been created.
And now that you've gone to all the trouble of creating that bug, I'm
probably just going to close it again, because that looks like exactly
the same crash this thread was all about. I just didn't know that C-x
5 2 would trigger it.
Do you have xemacs-uim installed?
In any case, if you feel adventurous, you can try installing the build
I just pushed to updates-testing:
http://admin.fedoraproject.org/updates/xemacs-packages-base-20090217-3.fc11
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:15 a.m.
Do you have xemacs-uim installed?
Yes.
In any case, if you feel adventurous, you can try installing the build
I just pushed to updates-testing:
http://admin.fedoraproject.org/updates/xemacs-packages-base-20090217-3.fc11
Done. Problem fixed. Thank you!
-Ram
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
2:57 a.m.
Jerry James writes:
On Mon, Aug 31, 2009 at 9:01 PM, Stephen J.
Turnbull<stephen(a)xemacs.org> wrote:
> However, there's also the question of how Lisp code can crash at all.
> Do you understand that mechanism?
The missing argument to the mule-util version of
truncate-string-to-width causes compute_menubar_data to return NULL
somehow. I still don't understand what's going on there. Then we
trigger the ABORT on line 579 of menubar-x.c.
I've never been able to figure that stuff out. :-(
However, a quick look shows that compute_menubar_data is *designed* to
return 0 in case of problems. So this isn't quite the case of "uh-oh,
trouble, let's make like the Uneasy Rider". It's a debugging assert,
really -- we want to preserve state as close to where the problem
happened as possible.
Unfortunately, I can't pinpoint where that abort got introduced (Ben's
abort->ABORT patch of 2005-01-24 in r2500 is what introduced that
line; the surrounding code comes from r428, which is a tag, r21-2-22
which would be late 1999...).
If there's a reasonable way to continue from there, now that we think
it can't happen, we should signal a Lisp error, not abort. I wonder
if there's a way to get at the information that call_trapping_problems
should provide for us, and display that.
We don't have a minimal reproducer anymore, since I nuked the
offending version of truncate-string-to-width. I've tried to find
other ways to trigger this crash, so far without success. The only
way I know how to do it is to redefine truncate-string-to-width to the
mule-util version. Maybe it should be something like this (where I'm
using old-truncate-string-to-width to avoid affecting the other
tests)?
That's fine.
Remember, the crashers are expected to be one-shot tests. :-)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
3:25 a.m.
On Wed, Sep 2, 2009 at 7:57 PM, Stephen J. Turnbull<stephen(a)xemacs.org> wrote:
I've never been able to figure that stuff out. :-(
However, a quick look shows that compute_menubar_data is *designed* to
return 0 in case of problems. So this isn't quite the case of "uh-oh,
trouble, let's make like the Uneasy Rider". It's a debugging assert,
really -- we want to preserve state as close to where the problem
happened as possible.
Unfortunately, I can't pinpoint where that abort got introduced (Ben's
abort->ABORT patch of 2005-01-24 in r2500 is what introduced that
line; the surrounding code comes from r428, which is a tag, r21-2-22
which would be late 1999...).
If there's a reasonable way to continue from there, now that we think
it can't happen, we should signal a Lisp error, not abort. I wonder
if there's a way to get at the information that call_trapping_problems
should provide for us, and display that.
Apparently, this is what menubar-msw.c is doing. All it took was one
look at Rodney's error message and I knew what was triggering the
problem. The menubar-x.c version was harder to diagnose.
That's fine.
Remember, the crashers are expected to be one-shot tests. :-)
Ha! By definition! Still, I'm working too hard. The body of
truncate-string-to-width doesn't matter at all. It is never executed.
It's the fact that it takes 4 parameters rather than 5 that matters.
So here's the final version, which I will commit shortly:
(defbug 12 current
"Crash when clicking on the menubar, triggered by a Lisp error due to a
version of truncate-string-to-width that does not take 5 parameters.
Fatal error: assertion failed, file menubar-x.c, line 579, ABORT()
Reported: https://bugzilla.redhat.com/show_bug.cgi?id=480845
<1251569781.4318.2.camel＠mslap>"
(fset 'truncate-string-to-width
#'(lambda (str end-column &optional start-column padding) str))
(accelerate-menu))
--
Jerry James
http://www.jamezone.org/(defun blowup ()
"Crash XEmacs."
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6:50 p.m.
Jerry James wrote:
Ah ha! So the mule-util.el version of truncate-string-to-width is
lacking the 3rd optional argument, ellipses, of the version in
subr.el. Thanks, Rodney!
Hi Jerry:
You are welcome. Unfortunately, during my testing I also discovered
a beta bug with respect to load-path: Issue 563 :o(
Rodney
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5559
days inactive
5564
days old
18 comments
5 participants
participants (5)
-
Jerry James -
Matthias Scheutz -
Ram Bhamidipaty -
Rodney Sparapani -
Stephen J. Turnbull