Re: Emacs 21.1 on HP-UX 10.20 behaves oddly

[Esa A E Peuha]

On Tue, 22 Jan 2002, Eli Zaretskii wrote:

> > (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.
>
> I'm not sure your analysis is correct.  DECODE_ISO_CHARACTER indeed
> calls translate_char with c=-1, but translate_char has this code at
> its beginning:
>
>     int
>     translate_char (table, c, charset, c1, c2)
>        Lisp_Object table;
>        int c, charset, c1, c2;
>     {
>       Lisp_Object ch;
>       int alt_charset, alt_c1, alt_c2, dimension;
>
>       if (c < 0) c = MAKE_CHAR (charset, (c1 & 0x7F) , (c2 & 0x7F));
>       if (!CHAR_TABLE_P (table)
>         || (ch = Faref (table, make_number (c)), !NATNUMP (ch)))
>       return c;
>
> So when c is negative, its value is computed as
>
>   MAKE_CHAR (charset, (c1 & 0x7F) , (c2 & 0x7F))
>
> It's possible that GDB shows the actual value of c at the moment of
> crash, not the value passed to translate_char when it was called.

This is indeed what happens.  I was jumping to conclusions.

> So could you please step with GDB through the beginning of
> translate_char, during the specific call which eventually causes
> Fsignal to be invoked, and see whether c is -1 initially?

It is.

> If this is indeed so, the next step is to see what kind of object is
> in idx inside Faref.  (I suspect some snafu with signed/unsigned, so
> please see whether the result of MAKE_CHAR above gets munged on its
> way through make_number and into Faref.)
>
> Also, I'm not sure that charset being -1 is okay, so please see what
> does MAKE_CHAR does in that case.

MAKE_CHAR (-1, 40, 3) evaluates as -14424, which is what Faref gets as
idx.  It certainly is not okay of charset to be -1; I think it should
be between 0 and MAX_CHARSET, but MAKE_CHAR doesn't check this.

> Finally, I wonder where does the string "\e(B2002-01-18", the one
> Emacs tries to decode, comes from?  It looks like it's 2002-01-18
> with an ISO-2022 leading escape sequence, but why would Emacs try to
> do something with that string during startup?  Could you try to find
> that out?

The "\e(B" part of the string is inserted by code_convert_string_norecord
when Fformat_time_string calls it to encode its format string; it then
formats the string (which doesn't change the escape sequence) and calls
code_convert_string_norecord again to decode the string, which fails.

-- 
Esa Peuha
student of mathematics at the University of Helsinki
http://www.helsinki.fi/~peuha/