From: Mike F. <mf...@su...> - 2004-12-29 15:53:42
Attachments:
test2.lisp
|
"Cedilla" by Juliusz Chroboczek (CC:) cannot handle non-ASCII file names, but while trying to find out why not, Juliusz said that this is due to a bug in clisp. I received the attached smalll test program "test2.lisp" from Juliusz. Using that test program with clisp 2.33.2, I see behavior described below: This is an AMD 64 bit machine, but the behaviour is identical on i386 systems: mfabian@magellan:~/clisp-bug$ uname -a Linux magellan 2.6.8-25-default #1 Mon Nov 15 09:44:13 UTC 2004 x86_64 x86_64 x86_64 GNU/Linux mfabian@magellan:~/clisp-bug$ SuSE Linux version is 9.2.1 (current development version of SuSE Linux) but the behavior is the same in the latest released version, SuSE Linux 9.2: mfabian@magellan:~/clisp-bug$ cat /etc/SuSE-release SUSE Linux 9.2.1 (x86-64) VERSION = 9.2.1 mfabian@magellan:~/clisp-bug$ Locale is ja_JP.UTF-8: mfabian@magellan:~/clisp-bug$ locale LANG=ja_JP.UTF-8 LC_CTYPE="ja_JP.UTF-8" LC_NUMERIC="ja_JP.UTF-8" LC_TIME="ja_JP.UTF-8" LC_COLLATE="ja_JP.UTF-8" LC_MONETARY="ja_JP.UTF-8" LC_MESSAGES="ja_JP.UTF-8" LC_PAPER="ja_JP.UTF-8" LC_NAME="ja_JP.UTF-8" LC_ADDRESS="ja_JP.UTF-8" LC_TELEPHONE="ja_JP.UTF-8" LC_MEASUREMENT="ja_JP.UTF-8" LC_IDENTIFICATION="ja_JP.UTF-8" LC_ALL= mfabian@magellan:~/clisp-bug$ Test program looks like this: mfabian@magellan:~/clisp-bug$ cat test2.lisp (print *pathname-encoding*) (print *args*) (with-open-file (in (car *args*)) (print (read-line in))) (print (parse-namestring (car *args*))) (ext:quit) mfabian@magellan:~/clisp-bug$ Executing the test program gives a Lisp stack overflow: mfabian@magellan:~/clisp-bug$ clisp -q test2.lisp test-äöü *** - Lisp stack overflow. RESET *** - Lisp stack overflow. RESET mfabian@magellan:~/clisp-bug$ Strangely enough, it even segfaults in de_DE.UTF-8 locale: mfabian@magellan:~/clisp-bug$ LANG=de_DE.UTF-8 clisp -q test2.lisp test-äöü セグメンテーション違反です (core dumped) mfabian@magellan:~/clisp-bug$ The error message "セグメンテーション違反です" is Japanese and means "Segmentation fault". Trying to get the "Segmentation fault" error message in English I get the "Lisp stack overflow" again. mfabian@magellan:~/clisp-bug$ LANG=de_DE.UTF-8 LC_MESSAGES=en_GB.UTF-8 clisp -q test2.lisp test-äöü *** - Lisp stack overflow. RESET *** - Lisp stack overflow. RESET mfabian@magellan:~/clisp-bug$ mfabian@magellan:~/clisp-bug$ |
From: Bruno H. <br...@cl...> - 2005-01-06 16:19:37
Attachments:
test2.lisp
|
Mike FABIAN wrote: > "Cedilla" by Juliusz Chroboczek (CC:) cannot handle non-ASCII file > names, but while trying to find out why not, Juliusz said that this is > due to a bug in clisp. I received the attached smalll test program > "test2.lisp" from Juliusz. > > Using that test program with clisp 2.33.2, I see behavior > described below: > ... >=20 > Locale is ja_JP.UTF-8: > > mfabian@magellan:~/clisp-bug$ locale > LANG=3Dja_JP.UTF-8 > LC_CTYPE=3D"ja_JP.UTF-8" > LC_NUMERIC=3D"ja_JP.UTF-8" > LC_TIME=3D"ja_JP.UTF-8" > LC_COLLATE=3D"ja_JP.UTF-8" > LC_MONETARY=3D"ja_JP.UTF-8" > LC_MESSAGES=3D"ja_JP.UTF-8" > LC_PAPER=3D"ja_JP.UTF-8" > LC_NAME=3D"ja_JP.UTF-8" > LC_ADDRESS=3D"ja_JP.UTF-8" > LC_TELEPHONE=3D"ja_JP.UTF-8" > LC_MEASUREMENT=3D"ja_JP.UTF-8" > LC_IDENTIFICATION=3D"ja_JP.UTF-8" > LC_ALL=3D > mfabian@magellan:~/clisp-bug$ > > Test program looks like this: > > mfabian@magellan:~/clisp-bug$ cat test2.lisp > (print *pathname-encoding*) > (print *args*) > (with-open-file (in (car *args*)) > (print (read-line in))) > (print (parse-namestring (car *args*))) > (ext:quit) > mfabian@magellan:~/clisp-bug$ > > Executing the test program gives a Lisp stack overflow: > > mfabian@magellan:~/clisp-bug$ clisp -q test2.lisp test-=EF=BF=BD=EF= =BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD > > *** - Lisp stack overflow. RESET > > *** - Lisp stack overflow. RESET > mfabian@magellan:~/clisp-bug$ > > Strangely enough, it even segfaults in de_DE.UTF-8 locale: > > mfabian@magellan:~/clisp-bug$ LANG=3Dde_DE.UTF-8 clisp -q test2.lisp > test-=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD =E3=82=BB=E3= =82=B0=E3=83=A1=E3=83=B3=E3=83=86=E3=83=BC=E3=82=B7=E3=83=A7=E3=83=B3=E9=81= =95=E5=8F=8D=E3=81=A7=E3=81=99 (core dumped) > mfabian@magellan:~/clisp-bug$ Strangely enough, I cannot reproduce this with clisp-2.33.2 built on a SuSE Linux 9.0 system: it all works fine for me. And I see nothing in the SuSE clisp RPM that could be at fault either. But since this gives a core dump on you side, could you please run $ gdb /usr/lib/clisp/base/lisp.run core (gdb) where and show the stack trace, so we get an idea about what's happening? Bruno |
From: Mike F. <mf...@su...> - 2005-01-06 22:17:47
|
Bruno Haible <br...@cl...> さんは書きました: > Strangely enough, I cannot reproduce this with clisp-2.33.2 built on a > SuSE Linux 9.0 system: it all works fine for me. And I see nothing in the > SuSE clisp RPM that could be at fault either. > > But since this gives a core dump on you side, could you please run > $ gdb /usr/lib/clisp/base/lisp.run core > (gdb) where > > and show the stack trace, so we get an idea about what's happening? You can reproduce neither the lisp stack overflow in ja_JP.UTF-8 nor the core dump in de_DE.UTF-8? Here is the stack trace: mfabian@magellan:~/clisp-bug$ LANG=de_DE.UTF-8 clisp -q test2.lisp test-äöü セグメンテーション違反です (core dumped) mfabian@magellan:~/clisp-bug$ gdb /usr/lib64/clisp/base/lisp.run core GNU gdb 6.3 Copyright 2004 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 "x86_64-suse-linux"...(no debugging symbols found) Using host libthread_db library "/lib64/tls/libthread_db.so.1". Core was generated by `/usr/lib64/clisp/base/lisp.run -B /usr/lib64/clisp -M /usr/lib64/clisp/base/lis'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib64/libreadline.so.5...(no debugging symbols found)...done. Loaded symbols for /lib64/libreadline.so.5 Reading symbols from /lib64/libncurses.so.5...(no debugging symbols found)...done. Loaded symbols for /lib64/libncurses.so.5 Reading symbols from /lib64/libdl.so.2... (no debugging symbols found)...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /lib64/tls/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib64/tls/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2... (no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /usr/lib64/gconv/ISO8859-1.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/gconv/ISO8859-1.so #0 0x00000000004b0608 in graphic_char_p () (gdb) bt #0 0x00000000004b0608 in graphic_char_p () #1 0x00000000004b10c0 in char_width () #2 0x00000000004532f0 in write_char () #3 0x00000000004b9b6e in C_gc () #4 0x00000000004b9c2f in C_gc () #5 0x00000000004ba2db in fehler () #6 0x00000000004406e0 in java_wcstombs () #7 0x000000000044094f in nls_asciiext_mbstowcs () #8 0x0000000000441be6 in n_char_to_string () #9 0x0000000000441c4d in asciz_to_string () #10 0x000000000041f402 in main () (gdb) -- Mike FABIAN <mf...@su...> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。 |
From: Bruno H. <br...@cl...> - 2005-01-10 21:41:46
|
Mike FABIAN wrote: > Bruno Haible <br...@cl...> さんは書きました: > > Strangely enough, I cannot reproduce this with clisp-2.33.2 built on a > > SuSE Linux 9.0 system: it all works fine for me. And I see nothing in the > > SuSE clisp RPM that could be at fault either. > > > > But since this gives a core dump on you side, could you please run > > $ gdb /usr/lib/clisp/base/lisp.run core > > (gdb) where > > > > and show the stack trace, so we get an idea about what's happening? > > You can reproduce neither the lisp stack overflow in ja_JP.UTF-8 nor the > core dump in de_DE.UTF-8? Yes. Also on an AMD64 machine on sourceforge, I can reproduce neither of the two. > Here is the stack trace: > (gdb) bt > #0 0x00000000004b0608 in graphic_char_p () > #1 0x00000000004b10c0 in char_width () > #2 0x00000000004532f0 in write_char () > #3 0x00000000004b9b6e in C_gc () > #4 0x00000000004b9c2f in C_gc () > #5 0x00000000004ba2db in fehler () > #6 0x00000000004406e0 in java_wcstombs () > #7 0x000000000044094f in nls_asciiext_mbstowcs () > #8 0x0000000000441be6 in n_char_to_string () > #9 0x0000000000441c4d in asciz_to_string () > #10 0x000000000041f402 in main () Ugh, this is a half-stripped binary: 'static' symbols have been removed. Nevertheless, I can get some information out of it: it looks to me like parts of charstrg.d or uni_attribute.c have been miscompiled by gcc. I would try to reduce the gcc optimization flags or try to compile clisp with a stock gcc-3.4.3 from ftp.gnu.org. Bruno |
From: Mike F. <mf...@su...> - 2005-01-11 02:25:36
|
Bruno Haible <br...@cl...> さんは書きました: > Mike FABIAN wrote: >> >> You can reproduce neither the lisp stack overflow in ja_JP.UTF-8 >> nor the core dump in de_DE.UTF-8? > > Yes. Also on an AMD64 machine on sourceforge, I can reproduce > neither of the two. Strange. >> Here is the stack trace: >> (gdb) bt >> #0 0x00000000004b0608 in graphic_char_p () >> #1 0x00000000004b10c0 in char_width () >> #2 0x00000000004532f0 in write_char () >> #3 0x00000000004b9b6e in C_gc () >> #4 0x00000000004b9c2f in C_gc () >> #5 0x00000000004ba2db in fehler () >> #6 0x00000000004406e0 in java_wcstombs () >> #7 0x000000000044094f in nls_asciiext_mbstowcs () >> #8 0x0000000000441be6 in n_char_to_string () >> #9 0x0000000000441c4d in asciz_to_string () >> #10 0x000000000041f402 in main () > > Ugh, this is a half-stripped binary: 'static' symbols have been removed. > Nevertheless, I can get some information out of it: it looks to me like > parts of charstrg.d or uni_attribute.c have been miscompiled by gcc. > > I would try to reduce the gcc optimization flags or try to compile clisp > with a stock gcc-3.4.3 from ftp.gnu.org. I compiled with "-O0" now. Same result, lisp stack overflow in ja_JP.UTF-8 and core dump in de_DE.UTF-8. Backtrace looks a bit different now. Is this backtrace more helpful?: mfabian@magellan:~/clisp-bug$ file /usr/lib64/clisp/base/lisp.run /usr/lib64/clisp/base/lisp.run: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), not stripped mfabian@magellan:~/clisp-bug$ LANG=de_DE.UTF-8 clisp -q test2.lisp test-äöü セグメンテーション違反です (core dumped) mfabian@magellan:~/clisp-bug$ gdb /usr/lib64/clisp/base/lisp.run core GNU gdb 6.3 Copyright 2004 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 "x86_64-suse-linux"...(no debugging symbols found) Using host libthread_db library "/lib64/tls/libthread_db.so.1". Core was generated by `/usr/lib64/clisp/base/lisp.run -B /usr/lib64/clisp -M /usr/lib64/clisp/base/lis'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib64/libreadline.so.5...(no debugging symbols found)...done. Loaded symbols for /lib64/libreadline.so.5 Reading symbols from /lib64/libncurses.so.5...(no debugging symbols found)...done. Loaded symbols for /lib64/libncurses.so.5 Reading symbols from /lib64/libdl.so.2... (no debugging symbols found)...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /lib64/tls/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib64/tls/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2... (no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /usr/lib64/gconv/ISO8859-1.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/gconv/ISO8859-1.so #0 0x00000000004b0608 in is_cjk_encoding () (gdb) bt #0 0x00000000004b0608 in is_cjk_encoding () #1 0x00000000004b10c0 in char_width () #2 0x00000000004532f0 in write_char () #3 0x00000000004b9b6e in write_errorasciz_substring () #4 0x00000000004b9c2f in write_errorstring () #5 0x00000000004ba2db in fehler () #6 0x00000000004406e0 in fehler_nls_invalid () #7 0x000000000044094f in nls_asciiext_mbstowcs () #8 0x0000000000441be6 in n_char_to_string () #9 0x0000000000441c4d in asciz_to_string () #10 0x000000000041f402 in main () (gdb) -- Mike FABIAN <mf...@su...> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。 |
From: Bruno H. <br...@cl...> - 2005-01-11 12:47:03
|
Mike FABIAN wrote: > (gdb) bt > #0 0x00000000004b0608 in is_cjk_encoding () > #1 0x00000000004b10c0 in char_width () > #2 0x00000000004532f0 in write_char () > #3 0x00000000004b9b6e in write_errorasciz_substring () > #4 0x00000000004b9c2f in write_errorstring () > #5 0x00000000004ba2db in fehler () > #6 0x00000000004406e0 in fehler_nls_invalid () > #7 0x000000000044094f in nls_asciiext_mbstowcs () > #8 0x0000000000441be6 in n_char_to_string () > #9 0x0000000000441c4d in asciz_to_string () > #10 0x000000000041f402 in main () Thanks. The appended patch should fix it; clisp should then complain about invalid bytes in the arguments. Bruno diff -c -3 -r1.267.2.5 spvw.d *** src/spvw.d 27 May 2004 11:04:21 -0000 1.267.2.5 --- src/spvw.d 11 Jan 2005 12:44:27 -0000 *************** *** 2676,2688 **** aktenv.block_env = NIL; aktenv.go_env = NIL; aktenv.decl_env = O(top_decl_env); - { /* init ARGV */ - uintL count; - O(argv) = allocate_vector(argc); - for (count=0; count<argc; count++) - TheSvector(O(argv))->data[count] = - asciz_to_string(argv[count],O(misc_encoding)); - } # everything completely initialized. {var struct backtrace_t bt; bt.bt_next = NULL; --- 2676,2681 ---- *************** *** 2761,2766 **** --- 2754,2768 ---- } skipSTACK(1); } + /* Init O(argv). */ + { + var uintL count; + O(argv) = allocate_vector(argc); + for (count=0; count<argc; count++) { + var object arg = asciz_to_string(argv[count],O(misc_encoding)); + TheSvector(O(argv))->data[count] = arg; + } + } /* print greeting: */ if (!nullpSv(quiet)) /* SYS::*QUIET* /= NIL ? */ { argv_verbose = 1; } /* prevents the greeting */ |
From: Mike F. <mf...@su...> - 2005-01-11 18:29:25
|
Bruno Haible <br...@cl...> =E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81= =8D=E3=81=BE=E3=81=97=E3=81=9F: > Mike FABIAN wrote: >> (gdb) bt >> #0 0x00000000004b0608 in is_cjk_encoding () >> #1 0x00000000004b10c0 in char_width () >> #2 0x00000000004532f0 in write_char () >> #3 0x00000000004b9b6e in write_errorasciz_substring () >> #4 0x00000000004b9c2f in write_errorstring () >> #5 0x00000000004ba2db in fehler () >> #6 0x00000000004406e0 in fehler_nls_invalid () >> #7 0x000000000044094f in nls_asciiext_mbstowcs () >> #8 0x0000000000441be6 in n_char_to_string () >> #9 0x0000000000441c4d in asciz_to_string () >> #10 0x000000000041f402 in main () > > Thanks. The appended patch should fix it; clisp should then complain ab= out > invalid bytes in the arguments. Yes, with that patch applied, the result of the test program is: mfabian@magellan:~/clisp-bug$ LANG=3Dja_JP.UTF-8 clisp -q test2.lisp test= -=C3=A4=C3=B6=C3=BC WARNING: *FOREIGN-ENCODING*: reset to ASCII #<ENCODING CHARSET:UTF-8 :UNIX>=20 ("test-=C3=A4=C3=B6=C3=BC")=20 "Hello, world!"=20 #P"test-=C3=A4=C3=B6=C3=BC"=20 mfabian@magellan:~/clisp-bug$ LANG=3Dde_DE.UTF-8 clisp -q test2.lisp test= -=C3=A4=C3=B6=C3=BC WARNING: *FOREIGN-ENCODING*: reset to ASCII #<ENCODING CHARSET:UTF-8 :UNIX>=20 ("test-=C3=A4=C3=B6=C3=BC")=20 "Hello, world!"=20 #P"test-=C3=A4=C3=B6=C3=BC" mfabian@magellan:~/clisp-bug$ and cedilla works as well for files with non-ASCII file names, although it prints a warning: mfabian@magellan:~/clisp-bug$ cedilla test-=C3=A4=C3=B6=C3=BC > ttt.ps WARNING: *FOREIGN-ENCODING*: reset to ASCII mfabian@magellan:~/clisp-bug$ --=20 Mike FABIAN <mf...@su...> http://www.suse.de/~mfabian =E7=9D=A1=E7=9C=A0=E4=B8=8D=E8=B6=B3=E3=81=AF=E3=81=84=E3=81=84=E4=BB=95=E4= =BA=8B=E3=81=AE=E6=95=B5=E3=81=A0=E3=80=82 |