Subject: [clisp-list] stack overflow - unknown charset

From: "Claudio Bley" <[email-masked]>
Date: Wed Jun 19 09:06:11 2002

Hi,

just as promised ;) in my previous mail I'm reporting my problems with
building cvs clisp 06/14/2002 :

I checked out clisp from cvs, did the usual steps:

$ ./configure with-gcc3
$ cd with-gcc3
$ ./makemake --with-readline --with-gettext --with-dynamic-ffi debug > Makefile
$ make config.lisp
$ make

which failed miserably at:

./lisp.run -B . -N locale -E UTF-8 -norc -m 750KW -x "(load \
\"init.lisp\") (sys::%saveinitmem) (exit)"

*** - Program stack overflow. RESET
make: *** [interpreted.mem] Segmentation fault

Here's the backtrace from gdb:

Program received signal SIGSEGV, Segmentation fault.
0x20264c8a in ?? ()
(gdb) bt
#0  0x20264c8a in ?? ()
#1  0x080fc390 in write_errorstring (
    errorstring=0x821c768 "unknown character set ~") at error.d:191
#2  0x080fc981 in fehler (errortype=error, 
    errorstring=0x821c768 "unknown character set ~") at error.d:328
#3  0x08092347 in open_iconv (to_code=0x819c59b "WCHAR_T", 
    from_code=0xbfffb9f0 "ARMSCII-8", charset=0x20277811) at stream.d:3611
#4  0x08092399 in check_charset (code=0xbfffb9f0 "ARMSCII-8", 
    charset=0x20277811) at stream.d:3621
#5  0x08077834 in C_make_encoding () at encoding.d:1707
#6  0x08078cd0 in init_encodings_2 () at encoding.d:2153
#7  0x080540b0 in initmem () at spvw.d:1407
#8  0x08055830 in main (argc=12, argv=0xbffffbf4) at spvw.d:2541

$ iconv --version
iconv (GNU libc) 2.2.5
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Ulrich Drepper.

$ 'iconv -l | grep -i armscii-8' 
# gives nothing

So it seems glibc's iconv in fact doesn't support this charset. The
same goes for the tcvn charset.

I just commented out the appropriate lines in src/constsym.d and the
build suceeded. Nonetheless, I guess it shouldn't segfault if the
charset is unknown...

System details:

Debian Gnu/Linux 3.0 (Woody) 
$ uname -a
Linux aptiva 2.4.18 #1 Mon May 13 15:24:42 CEST 2002 i686 unknown
$ gcc --version
3.0.4

Claudio

---

From: Sam Steingold <[email-masked]>
Date: Wed Jun 19 09:55:07 2002

> * In message <[email-masked]>
> * On the subject of "[clisp-list] stack overflow - unknown charset"
> * Sent on Wed, 19 Jun 2002 18:05:00 +0200
> * Honorable "Claudio Bley" <[email-masked]> writes:
>

on my redhat gnu/linux 7.3 with the glibc 2.2.5 both armscii-8 and tcvn
are present.

> build suceeded. Nonetheless, I guess it shouldn't segfault if the

you are right - please try the appended patch and report your
experiences.  (you will also need to copy the definition of
CLISP_INTERNAL_CHARSET from stream.d)

> Linux aptiva 2.4.18 #1 Mon May 13 15:24:42 CEST 2002 i686 unknown

BTW, Bruno, why now, after HAVE_GOOD_ICONV has already been introduced,
we still have GLIBC version checks in encoding.d?

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Only a fool has no doubts.

--- encoding.d.~1.68.~	Wed Jun 12 09:22:58 2002
+++ encoding.d	Wed Jun 19 12:50:50 2002
@@ -2151,10 +2151,21 @@
     var object symbol = iconv_first_sym;
     var uintC count;
     dotimesC(count,iconv_num_encodings, {
+      var bool good_p = true;
+      with_string_0(Symbol_name(symbol),Symbol_value(S(ascii)),charset_ascii,{
+        var iconv_t cd = iconv_open(CLISP_INTERNAL_CHARSET,charset_ascii);
+        good_p = ((cd != -1) && (iconv_close(cd) >= 0)
+                  && ((cd=iconv_open(charset_ascii,CLISP_INTERNAL_CHARSET)) != -1)
+                  && (iconv_close(cd) >= 0));
+      });
+      if (good_p) {
       pushSTACK(Symbol_name(symbol));
       pushSTACK(unbound); pushSTACK(unbound); pushSTACK(unbound);
       C_make_encoding(); # cannot use funcall yet
       define_constant(symbol,value1);
+      } else {
+        pushSTACK(symbol); pushSTACK(O(charset_package)); C_unintern();
+      }
       symbol = objectplus(symbol,(soint)sizeof(*TheSymbol(symbol))<<(oint_addr_shift-addr_shift));
     });
   }

---

From: Bruno Haible <[email-masked]>
Date: Wed Jun 19 11:14:05 2002

> > same goes for the tcvn charset.

You're right. I've changed constsym.d now to include these charsets
only with glibc >= 2.3. I was misled because the support for these
charsets was added a few weeks before the release of glibc-2.2.5, but
only on the development branch of glibc.

> on my redhat gnu/linux 7.3 with the glibc 2.2.5 both armscii-8 and tcvn

RedHat is well-known for shipping development versions of gcc or glibc
(remember gcc-2.96 or glibc-2.1.96?)

Bruno

---

From: Sam Steingold <[email-masked]>
Date: Wed Jun 19 12:12:05 2002

> building cvs clisp 06/14/2002 :

please update your cvs sandbox and reconfigure.
thanks.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Never underestimate the power of stupid people in large groups.

---

From: "Claudio Bley" <[email-masked]>
Date: Wed Jun 19 17:47:03 2002

>>>>> "Sam" == Sam Steingold <[email-masked]> writes:

    >> * In message
    >> <[email-masked]> * On the
    >> subject of "[clisp-list] stack overflow - unknown charset" *
    >> Sent on Wed, 19 Jun 2002 18:05:00 +0200 * Honorable "Claudio
    >> Bley" <[email-masked]> writes:
    >> 
    >> just as promised ;) in my previous mail I'm reporting my
    >> problems with building cvs clisp 06/14/2002 :

    Sam> please update your cvs sandbox and reconfigure.  thanks.

I just did this and it compiled without any problems (of course :). 

Thanks,
Claudio

---

From: Kaz Kylheku <[email-masked]>
Date: Sat Jun 29 17:47:01 2002

[15]> (macroexpand '(setf (car x) y))
(SYSTEM::%RPLACA X Y) ;
T

So far so good. But:

[16]> (macroexpand '(setf (aref x y) z))
(LET* ((#:G1267 X) (#:G1268 Y) (#:G1269 Z))
 (SYSTEM::STORE #:G1267 #:G1268 #:G1269)) ;
T
[17]> (macroexpand '(setf (gethash x y) z))
(LET* ((#:G1270 X) (#:G1271 Y) (#:G1272 Z))
 (SYSTEM::PUTHASH #:G1270 #:G1271 #:G1272)) ;
T
[19]> (macroexpand '(setf (seventh x) y))
(LET* ((#:G1275 X) (#:G1276 Y))
 (SYSTEM::%RPLACA (CDDR (CDDDDR #:G1275)) #:G1276)) ;
T

What?  Why not simply:

    (SYSTEM::STORE X Y Z)
    (SYSTEM::PUTHASH X Y Z)
    (SYSTEM::RPLACA (CDDR (CDDDDR X)) Y)

There are no variable capture issues, nor multiple evaluations
of the parameters.

Are not the parameters to SYSTEM::STORE and others evaluated
left to right? Even if that was the reason, there is no reason to use let*
to bind the gensyms, because let* merely ensures an order of establishment
of the *bindings*. With plain let, evaluation is still left to right,
but the bindings to the symbols are established in parallel.  Since the
initializing expressions cannot refer to the gensyms, let* is
unnecessary.

Am I missing something, or should I make a patch? ;)
Or would it be faster to make a patch anyway and later be told I'm
missing something? ;)

---

From: "Thomas F. Burdick" <[email-masked]>
Date: Sat Jun 29 18:21:01 2002

>  (SYSTEM::STORE #:G1267 #:G1268 #:G1269)) ;
[...]
 >     (SYSTEM::STORE X Y Z)

Why do you care?  Hint, have you tried compiling the code?  You get
the same bytecodes for FOO and BAR:

  (defun foo (a i v) (system::store a i v))
  (defun bar (a i v) (setf (aref a i) v))

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'