8:24 a.m.
In CVS current, Mule on X crashes immediately. This may be related to
Japanese hardware; the keysym that blows up is 1223 decimal, which
puts it in the KATAKANA_JISX0201 range. (Cf x_keysym_to_character(),
src/event-Xt.c:211.)
`xemacs -nw -vanilla' does not crash.
$ src/xemacs -vanilla &
Fatal error: assertion failed, file /coda/Projects/XEmacs/21.2-HEAD/src/mule-charset.h,
line 569, lb >= 0x80 && lb <= 0xFF
[...]
Lisp backtrace follows:
# (unwind-protect ...)
make-device(x nil)
# bind (display)
make-x-device(nil)
init-x-win()
# bind (debugger debug-on-error command-line-args-left)
command-line()
# (unwind-protect ...)
normal-top-level()
# (condition-case ... . error)
# (catch top-level ...)
[2]+ Aborted src/xemacs -vanilla
C backtrace:
bash-2.04$ gdb src/xemacs
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) run -vanilla
Starting program: /home/steve/Projects/XEmacs/Builds/21.2/src/xemacs -vanilla
Fatal error: assertion failed, file /coda/Projects/XEmacs/21.2-HEAD/src/mule-charset.h,
line 569, lb >= 0x80 && lb <= 0xFF
Program received signal SIGABRT, Aborted.
0x40396e71 in kill () from /lib/libc.so.6
(gdb) where
#0 0x40396e71 in kill () from /lib/libc.so.6
#1 0x40396b54 in raise () from /lib/libc.so.6
#2 0x40398261 in abort () from /lib/libc.so.6
#3 0x80ca76b in assert_failed (
file=0x82e0080 "/coda/Projects/XEmacs/21.2-HEAD/src/mule-charset.h",
line=569, expr=0x82e00b3 "lb >= 0x80 && lb <= 0xFF")
at /coda/Projects/XEmacs/21.2-HEAD/src/emacs.c:3189
#4 0x8217467 in x_keysym_to_character (keysym=1223)
at /coda/Projects/XEmacs/21.2-HEAD/src/mule-charset.h:569
#5 0x8217750 in x_has_keysym (keysym=1223, hash_table={gu = {
type = Lisp_Type_Record, val = 34853898}, s = {bits = 0,
val = 69707796}, u = {bits = 0, val = 69707796}, ui = 139415592,
i = 139415592, v = 0x84f5028, cv = 0x84f5028}, with_modifiers=1)
at /coda/Projects/XEmacs/21.2-HEAD/src/event-Xt.c:306
#6 0x821799a in x_reset_key_mapping (d=0x848ee70)
at /coda/Projects/XEmacs/21.2-HEAD/src/event-Xt.c:406
#7 0x8217a78 in x_reset_modifier_mapping (d=0x848ee70)
at /coda/Projects/XEmacs/21.2-HEAD/src/event-Xt.c:461
#8 0x821d6ba in x_init_modifier_mapping (d=0x848ee70)
at /coda/Projects/XEmacs/21.2-HEAD/src/event-Xt.c:625
#9 0x8214880 in x_init_device (d=0x848ee70, props={gu = {
type = Lisp_Type_Record, val = 269853648}, s = {bits = 0,
val = 539707296}, u = {bits = 0, val = 539707296}, ui = 1079414592,
i = 1079414592, v = 0x40568f40, cv = 0x40568f40})
at /coda/Projects/XEmacs/21.2-HEAD/src/device-x.c:803
#10 0x80b73dc in Fmake_device (type={gu = {type = Lisp_Type_Record,
val = 269850822}, s = {bits = 0, val = 539701644}, u = {bits = 0,
val = 539701644}, ui = 1079403288, i = 1079403288, v = 0x40566318,
cv = 0x40566318}, connection={gu = {type = Lisp_Type_Record,
val = 269853648}, s = {bits = 0, val = 539707296}, u = {bits = 0,
val = 539707296}, ui = 1079414592, i = 1079414592, v = 0x40568f40,
cv = 0x40568f40}, props={gu = {type = Lisp_Type_Record,
val = 269853648}, s = {bits = 0, val = 539707296}, u = {bits = 0,
val = 539707296}, ui = 1079414592, i = 1079414592, v = 0x40568f40,
cv = 0x40568f40}) at /coda/Projects/XEmacs/21.2-HEAD/src/device.c:588
#11 0x80d1bae in Ffuncall (nargs=3, args=0xbfffee78)
at /coda/Projects/XEmacs/21.2-HEAD/src/eval.c:3528
#12 0x809d02e in execute_optimized_program (
program=0x8434480 "ÁÂ\b\"\207 by ", stack_depth=3,
constants_data=0x406141fc)
at /coda/Projects/XEmacs/21.2-HEAD/src/bytecode.c:746
#13 0x809cbb4 in funcall_compiled_function (fun={gu = {
type = Lisp_Type_Record, val = 270077235}, s = {bits = 0,
val = 540154470}, u = {bits = 0, val = 540154470}, ui = 1080308940,
i = 1080308940, v = 0x406434cc, cv = 0x406434cc}, nargs=1,
args=0xbffff0cc) at /coda/Projects/XEmacs/21.2-HEAD/src/bytecode.c:518
#14 0x80d1d10 in Ffuncall (nargs=2, args=0xbffff0c8)
at /coda/Projects/XEmacs/21.2-HEAD/src/eval.c:3563
#15 0x809d02e in execute_optimized_program (
program=0x848e990 "\f?\037Å
\210\b＠\013B\022ÆÁ!«\b\t¬\005ÇÈ!\021ÉÊ!\210\nA\023Ë\211\024\207f)", stack_depth=2,
constants_data=0x40600890)
at /coda/Projects/XEmacs/21.2-HEAD/src/bytecode.c:746
#16 0x809cbb4 in funcall_compiled_function (fun={gu = {
type = Lisp_Type_Record, val = 270071089}, s = {bits = 0,
val = 540142178}, u = {bits = 0, val = 540142178}, ui = 1080284356,
i = 1080284356, v = 0x4063d4c4, cv = 0x4063d4c4}, nargs=0,
args=0xbffff31c) at /coda/Projects/XEmacs/21.2-HEAD/src/bytecode.c:518
#17 0x80d1d10 in Ffuncall (nargs=1, args=0xbffff318)
at /coda/Projects/XEmacs/21.2-HEAD/src/eval.c:3563
#18 0x809d02e in execute_optimized_program (
program=0x848e798 "\013A\035ÆÇ\032\031È\r!\025ÉÊ!«\004Ë
\210\f«\016\b¬\013ÌÍÎ\f!ÏQ! \210Ð \210*Ñ \210Ò \210rÓÔ!q\210Õ
\210Ö×!\210\016\036Øa«\005\016\037 \210)Ù Úa«\bÀ ¬\004Û \210Ü \210×\026 À
\004ÝÇ!)\207steA\001", stack_depth=4,
constants_data=0x4060f99c)
at /coda/Projects/XEmacs/21.2-HEAD/src/bytecode.c:746
#19 0x809cbb4 in funcall_compiled_function (fun={gu = {
type = Lisp_Type_Record, val = 270076073}, s = {bits = 0,
val = 540152146}, u = {bits = 0, val = 540152146}, ui = 1080304292,
i = 1080304292, v = 0x406422a4, cv = 0x406422a4}, nargs=0,
args=0xbffff57c) at /coda/Projects/XEmacs/21.2-HEAD/src/bytecode.c:518
#20 0x80d1d10 in Ffuncall (nargs=1, args=0xbffff578)
at /coda/Projects/XEmacs/21.2-HEAD/src/eval.c:3563
#21 0x809d02e in execute_optimized_program (
program=0x8407ad8 "\t«\005ÆÇ!\207È\021É
\211\034«\025\fG\rGW«\016Ê\r!Ê\f!k«\005Ë\f!\025)Ì\r!\025Í \210Î
\210\013®\aÏÐ!\002È\eÑ\016#\016$\"\022\013«\tÒÓÔ\n\"Õ\"\210\n¬\006Ö
\210ª\013×\n\016%\b\016&\013%\210Ø
\210)\016!¬\022\016\"«\016ÙÚÛ\016'!\016\"\"ÜÈ#\210\016!¬\023\b¬\006Ý\016(!\210Ý\016)!\210Ý\016*!\210Þ\216ß
\210)\016+\003à \207", stack_depth=7, constants_data=0x406100a4)
at /coda/Projects/XEmacs/21.2-HEAD/src/bytecode.c:746
#22 0x809cbb4 in funcall_compiled_function (fun={gu = {
type = Lisp_Type_Record, val = 270076290}, s = {bits = 0,
val = 540152580}, u = {bits = 0, val = 540152580}, ui = 1080305160,
i = 1080305160, v = 0x40642608, cv = 0x40642608}, nargs=0,
args=0xbffff714) at /coda/Projects/XEmacs/21.2-HEAD/src/bytecode.c:518
#23 0x80d16af in Feval (form={gu = {type = Lisp_Type_Record, val = 269923146},
s = {bits = 0, val = 539846292}, u = {bits = 0, val = 539846292},
ui = 1079692584, i = 1079692584, v = 0x405acd28, cv = 0x405acd28})
at /coda/Projects/XEmacs/21.2-HEAD/src/eval.c:3388
#24 0x80cd028 in condition_case_1 (handlers={gu = {type = Lisp_Type_Record,
val = 269853552}, s = {bits = 0, val = 539707104}, u = {bits = 0,
val = 539707104}, ui = 1079414208, i = 1079414208, v = 0x40568dc0,
cv = 0x40568dc0}, bfun=0x80d0b30 <Feval>, barg={gu = {
type = Lisp_Type_Record, val = 269923146}, s = {bits = 0,
val = 539846292}, u = {bits = 0, val = 539846292}, ui = 1079692584,
i = 1079692584, v = 0x405acd28, cv = 0x405acd28},
hfun=0x80acbbc <cmd_error>, harg={gu = {type = Lisp_Type_Record,
val = 269853648}, s = {bits = 0, val = 539707296}, u = {bits = 0,
val = 539707296}, ui = 1079414592, i = 1079414592, v = 0x40568f40,
cv = 0x40568f40}) at /coda/Projects/XEmacs/21.2-HEAD/src/eval.c:1651
#25 0x80acc6d in top_level_1 (dummy={gu = {type = Lisp_Type_Record,
val = 269853648}, s = {bits = 0, val = 539707296}, u = {bits = 0,
val = 539707296}, ui = 1079414592, i = 1079414592, v = 0x40568f40,
cv = 0x40568f40}) at /coda/Projects/XEmacs/21.2-HEAD/src/cmdloop.c:206
#26 0x80d69e7 in internal_catch (tag={gu = {type = Lisp_Type_Record,
val = 269804556}, s = {bits = 0, val = 539609112}, u = {bits = 0,
val = 539609112}, ui = 1079218224, i = 1079218224, v = 0x40539030,
cv = 0x40539030}, func=0x80acc34 <top_level_1>, arg={gu = {
type = Lisp_Type_Record, val = 269853648}, s = {bits = 0,
val = 539707296}, u = {bits = 0, val = 539707296}, ui = 1079414592,
i = 1079414592, v = 0x40568f40, cv = 0x40568f40}, threw=0x0)
at /coda/Projects/XEmacs/21.2-HEAD/src/eval.c:1317
#27 0x80abd29 in initial_command_loop (load_me={gu = {type = Lisp_Type_Record,
val = 269853648}, s = {bits = 0, val = 539707296}, u = {bits = 0,
val = 539707296}, ui = 1079414592, i = 1079414592, v = 0x40568f40,
cv = 0x40568f40}) at /coda/Projects/XEmacs/21.2-HEAD/src/cmdloop.c:285
#28 0x80c87e4 in sort_args (argc=2, argv=0xbffffca4)
at /coda/Projects/XEmacs/21.2-HEAD/src/emacs.c:2228
#29 0x80ca9fb in main (argc=2, argv=0xbffffca4, envp=0xbffffcb0)
at /coda/Projects/XEmacs/21.2-HEAD/src/emacs.c:2595
#30 0x40387bcc in __libc_start_main () from /lib/libc.so.6
Installation:
uname -a: Linux tleepslib 2.4.0-test7 #1 Thu Sep 7 18:30:33 JST 2000 i686 unknown
/coda/Projects/XEmacs/21.2-HEAD/configure
'--srcdir=/coda/Projects/XEmacs/21.2-HEAD' '--with-widgets=athena'
'--with-athena=3d' '--with-dialogs=athena' '--with-sound=none,nas'
'--with-mule' '--with-xim=xlib' '--with-xfs'
'--use-union-type' '--pdump'
XEmacs 21.2-b36 "Notus" configured for `i686-pc-linux'.
Compilation / Installation:
Source code location: /coda/Projects/XEmacs/21.2-HEAD
Installation prefix: /usr/local
Operating system description file: `s/linux.h'
Machine description file: `m/intel386.h'
Compiler: gcc -g -O3 -Wall -Wno-switch -Wpointer-arith -Winline
-Wmissing-prototypes -Wshadow
Relocating allocator for buffers: no
GNU version of malloc: yes
- Using Doug Lea's new malloc from the GNU C Library.
Window System:
Compiling in support for the X window system:
- X Windows headers location: /usr/X11R6/include
- X Windows libraries location: /usr/X11R6/lib
- Handling WM_COMMAND properly.
Compiling in support for the Athena widget set:
- Athena headers location: X11/Xaw3d
- Athena library to link: Xaw3d
Using Lucid menubars.
Using Lucid scrollbars.
Using Athena dialog boxes.
Using Athena native widgets.
TTY:
Compiling in support for ncurses.
Images:
Compiling in support for GIF images (builtin).
Compiling in support for XPM images.
Compiling in support for PNG images.
Compiling in support for JPEG images.
Compiling in support for TIFF images.
Sound:
Compiling in support for NAS (network audio system).
Databases:
Compiling in support for Berkeley database.
Compiling in support for PostgreSQL.
- Using PostgreSQL header file: postgresql/libpq-fe.h
- Using PostgreSQL V7 bindings.
Internationalization:
Compiling in support for Mule (multi-lingual Emacs).
Compiling in support for XIM (X11R5+ I18N input method).
- Using raw Xlib to provide XIM support.
- Using XFontSet to provide bilingual menubar.
Compiling in support for Canna on Mule.
Compiling in support for the WNN input method on Mule.
Mail:
Compiling in support for "dot-locking" mail spool file locking method.
Other Features:
Compiling in support for dynamic shared object modules.
Using the union type for Lisp_Objects.
Using the new portable dumper.
Compiling in support for extra debugging code.
WARNING: ---------------------------------------------------------
WARNING: Compiling in support for runtime error checking.
WARNING: XEmacs will run noticeably more slowly as a result.
WARNING: Error checking is on by default for XEmacs beta releases.
WARNING: ---------------------------------------------------------
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
8:53 a.m.
I WILL NOT APPLY without support from someone who knows what's going
on here.
>>>> "Stephen" == Stephen J Turnbull
<turnbull(a)sk.tsukuba.ac.jp> writes:
Stephen> In CVS current, Mule on X crashes immediately. This may
Stephen> be related to Japanese hardware; the keysym that blows up
Stephen> is 1223 decimal, which puts it in the KATAKANA_JISX0201
Stephen> range. (Cf x_keysym_to_character(), src/event-Xt.c:211.)
This seems to fix but I don't understand why. x_keysym_to_character()
from src/events-Xt.c should call this macro with a value that was
originally an enum constant (ie, int) LEADING_BYTE_KATAKANA_JISX0201
== 0x89 from src/mule-charset.h. This should fit into a Bufbyte
(typedef for unsigned char), right?
GCC bug, maybe?
$ gcc --version
2.95.2
# debian woody (unstable)
$ dpkg -l gcc
||/ Name Version Description
+++-==============-==============-============================================
ii gcc 2.95.2-14 The GNU C compiler.
src/ChangeLog:
2000-11-04 Stephen J. Turnbull <stephen(a)xemacs.org>
* mule-charset.h: Change type of argument of
CHARSET_BY_LEADING_BYTE back to int (fixes
<14851.51148.36400.105153(a)turnbull.sk.tsukuba.ac.jp>)
Index: src/mule-charset.h
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/mule-charset.h,v
retrieving revision 1.7.2.16
diff -u -r1.7.2.16 mule-charset.h
--- mule-charset.h 2000/10/12 04:59:05 1.7.2.16
+++ mule-charset.h 2000/11/04 08:43:26
＠＠ -560,9 +560,9 ＠＠
Bufbyte next_allocated_2_byte_leading_byte;
};
-INLINE_HEADER Lisp_Object CHARSET_BY_LEADING_BYTE (Bufbyte lb);
+INLINE_HEADER Lisp_Object CHARSET_BY_LEADING_BYTE (int lb);
INLINE_HEADER Lisp_Object
-CHARSET_BY_LEADING_BYTE (Bufbyte lb)
+CHARSET_BY_LEADING_BYTE (int lb)
{
extern struct charset_lookup *chlook;
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
4:58 a.m.
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
>>>>> "Stephen" == Stephen J Turnbull
<turnbull(a)sk.tsukuba.ac.jp> writes:
Stephen> In CVS current, Mule on X crashes immediately. This may
Stephen> be related to Japanese hardware; the keysym that blows up
Stephen> is 1223 decimal, which puts it in the KATAKANA_JISX0201
Stephen> range. (Cf x_keysym_to_character(), src/event-Xt.c:211.)
This seems to fix but I don't understand why. x_keysym_to_character()
from src/events-Xt.c should call this macro with a value that was
originally an enum constant (ie, int) LEADING_BYTE_KATAKANA_JISX0201
== 0x89 from src/mule-charset.h. This should fit into a Bufbyte
(typedef for unsigned char), right?
GCC bug, maybe?
$ gcc --version
2.95.2
I guess so.
There was the same crash report from himi.
"assertion of CHARSET_BY_LEADING_BYTE fails on gcc-2.95.2 20000220."
<uvguvg532.fsf(a)MILCH.meadow.scphys.kyoto-u.ac.jp>
Sat, 14 Oct 2000 18:11:29 +0900
I don't know why it doesn't happen to me (I'm using Debian
woody). There are already some hack to remedy GCC optimizer
bug which I don't like very much because it tend to worsen
readability. But if it happens to many people, something
should be done.
--
Yoshiki Hayashi
6:37 a.m.
>>>> "SJT" == Stephen J Turnbull
<turnbull(a)sk.tsukuba.ac.jp> writes:
SJT> I WILL NOT APPLY without support from someone who knows what's going
SJT> on here.
>>>> "Stephen" == Stephen J Turnbull
<turnbull(a)sk.tsukuba.ac.jp> writes:
Stephen> In CVS current, Mule on X crashes immediately. This may
Stephen> be related to Japanese hardware; the keysym that blows up
Stephen> is 1223 decimal, which puts it in the KATAKANA_JISX0201
Stephen> range. (Cf x_keysym_to_character(), src/event-Xt.c:211.)
SJT> This seems to fix but I don't understand why. x_keysym_to_character()
SJT> from src/events-Xt.c should call this macro with a value that was
SJT> originally an enum constant (ie, int) LEADING_BYTE_KATAKANA_JISX0201
SJT> == 0x89 from src/mule-charset.h. This should fit into a Bufbyte
SJT> (typedef for unsigned char), right?
This was my change.
I can't reproduce this, and of course I have gcc 2.95 as well.
If I do
xmodmap -e 'keysym F10 = F10 kana_NU'
Then press [(shift f10)], I see a real live kana character in my
xemacs buffer.
I would like to keep the arg of CHARSET_BY_LEADING_BYTE as is, since
it is actually logically a bufbyte.
SJT> GCC bug, maybe?
Maybe. Is it possible inline functions with unsigned char arguments
don't have proper conversions from int?
Could you investigate some more?
If you load a cyrillic keyboard mapping before starting X, do you have
the same problem? Is it dependent on compiler flags?
Martin
8:55 a.m.
>>>> "mb" == Martin Buchholz
<martin(a)xemacs.org> writes:
mb> I would like to keep the arg of CHARSET_BY_LEADING_BYTE as is,
mb> since it is actually logically a bufbyte.
No, it's not, in this case; it's an enum LEADING_BYTE_OFFICIAL_1. The
point being that there are several ways to hit that assert, and not
all of them pass through a buffer. From the comment in the preceding
version (which you should not have deleted; you should have disagreed
with it), that's exactly the reasoning that led to the arg being an
int in the first place.
I agree that we _wish_ it were a Bufbyte, but if we were all that
confident of that, we wouldn't need the assert. A real buffer byte
that gets fed to that assert presumably was acquired via
VALIDATE_CHARPTR_BACKWARD and friends, and already passes the assert.
IIRC, leading bytes are also used to identify charsets in redisplay
internals. It's not so hard to imagine a programming error in which
an Emchar gets put somewhere that eventually ends up hitting that
assert, is it?
SJT> GCC bug, maybe?
mb> Maybe. Is it possible inline functions with unsigned char
mb> arguments don't have proper conversions from int?
As karlheg would say "you tell me and we'll both know". I'm not a
member of the bar in C.
Note that as I mention above the argument also has to be converted
first from enum LBO1 to Bufbyte; this would imply a GCC bug, though,
because that conversion should already be a fact when the assert is
hit.
I'm more suspicious of this type_checking_assert. What is it? Is
this a C9x thing?
mb> Could you investigate some more?
Yes. You've probably seen Yoshiki's message already, but there's
himi's report "assertion of CHARSET_BY_LEADING_BYTE fails on
gcc-2.95.2 20000220." himi says -O0 wins for him and provides
assembler output to show why. I haven't tried it, will do so if you
insist.
Yoshiki's suggestion of -fno-gcse in that thread does NOT win for me,
it pukes on the same assertion with the same C backtrace that Himi and
I have both posted (I checked that Himi's is the same).
mb> If you load a cyrillic keyboard mapping before starting X, do
mb> you have the same problem?
Yes, I do (on keysym 1738, which is in the Cyrillic range according to
the logic in event-Xt.c).
mb> Is it dependent on compiler flags?
Any further suggestions for compiler flags to try?
Better hurry, XF86 4.0 just showed up in Debian woody, and I probably
won't have a reliable workstation to test on for a couple of weeks
after "upgrading" to that :-P
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
8782
days inactive
8784
days old
4 comments
3 participants
participants (3)
-
Martin Buchholz -
Stephen J. Turnbull -
Yoshiki Hayashi