[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs 21.1 on HP-UX 10.20 behaves oddly
From: |
Esa A E Peuha |
Subject: |
Re: Emacs 21.1 on HP-UX 10.20 behaves oddly |
Date: |
Mon, 21 Jan 2002 14:27:27 +0200 (EET) |
On Fri, 18 Jan 2002, Eli Zaretskii wrote:
> The value of the LC_* environment variables, the value of
> default-enable-multibyte-characters, and the value of
> locale-coding-system (the latter 2 are not in the checklist, but they
> might help).
LC_CTYPE=fi_FI.iso88591
default-enable-multibyte-characters t
locale-coding-system iso-latin-1
> Okay, then please run Emacs under GDB, put a breakpoint in the
> function Fsignal, and when it breaks, type "xbacktrace" and post the
> backtrace produced by that.
(gdb) xbacktrace
Argument to arithmetic operation not a number or boolean.
I suppose this is because Emacs is not yet executing Lisp code at that
point. (Maybe xbacktrace should detect this and give a better message.)
However, the backtrace of C functions is more interesting:
(gdb) backtrace
#0 Fsignal (error_symbol=269674764, data=1345766972) at eval.c:1375
#1 0x18ca20 in args_out_of_range (a1=1075650560, a2=268421032)
at data.c:137
#2 0x191b10 in Faref (array=1075650560, idx=268421032) at data.c:1778
#3 0x75ff4 in translate_char (table=1075650560, c=-14424, charset=-1,
c1=40, c2=3) at charset.c:376
#4 0x82c64 in $0000016D () at coding.c:2024
#5 0x8cfcc in decode_coding (coding=0x7b03ba10, source=0x403809a4
"\e(B2002-01-18", destination=0x40378c08
"\e(B/h/6/matl/peuha/.emacs.d/auto-save-listterm.el", src_bytes=13,
dst_bytes=295) at coding.c:4710
#6 0x91b40 in decode_coding_string (str=807997220, coding=0x7b03ba10,
nocopy=1) at coding.c:5908
#7 0x94200 in code_convert_string_norecord (string=807997220,
coding_system=270307572, encodep=0) at coding.c:6586
#8 0x19cfa0 in Fformat_time_string (format_string=807997236,
time=1342356960, universal=269552644) at editfns.c:1544
#3 shows that translate_char is called with bogus arguments; #4 points
to a invocation of macro DECODE_ISO_CHARACTER in decode_coding_iso2022,
but DECODE_ISO_CHARACTER is defined to call translate_char with c=-1,
not -14424. So, it appears that the file coding.c is miscompiled by the
native cc of HP-UX.
--
Esa Peuha
student of mathematics at the University of Helsinki
http://www.helsinki.fi/~peuha/
- Emacs 21.1 on HP-UX 10.20 behaves oddly, Esa A E Peuha, 2002/01/16
- Re: Emacs 21.1 on HP-UX 10.20 behaves oddly, Eli Zaretskii, 2002/01/16
- Re: Emacs 21.1 on HP-UX 10.20 behaves oddly, Esa A E Peuha, 2002/01/17
- Re: Emacs 21.1 on HP-UX 10.20 behaves oddly, Eli Zaretskii, 2002/01/17
- Re: Emacs 21.1 on HP-UX 10.20 behaves oddly, Esa A E Peuha, 2002/01/18
- Re: Emacs 21.1 on HP-UX 10.20 behaves oddly, Eli Zaretskii, 2002/01/18
- Re: Emacs 21.1 on HP-UX 10.20 behaves oddly,
Esa A E Peuha <=
- Re: Emacs 21.1 on HP-UX 10.20 behaves oddly, Eli Zaretskii, 2002/01/22
- Re: Emacs 21.1 on HP-UX 10.20 behaves oddly, Richard Stallman, 2002/01/22
- Re: Emacs 21.1 on HP-UX 10.20 behaves oddly, Esa A E Peuha, 2002/01/23
- Re: Emacs 21.1 on HP-UX 10.20 behaves oddly, Eli Zaretskii, 2002/01/23
- Re: Emacs 21.1 on HP-UX 10.20 behaves oddly, Esa A E Peuha, 2002/01/24