bug-gnu-emacs
[Top][All Lists]
Advanced

[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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]