From: SourceForge.net <no...@so...> - 2005-07-03 11:42:57
|
Bugs item #1231762, was opened at 2005-07-03 07:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: segfault Status: Open Resolution: None Priority: 5 Submitted By: John Hinsdale (hin) Assigned to: Sam Steingold (sds) Summary: (ERROR large-string) gives seg fault Initial Comment: When I call ERROR with a large message, CLISP seg. faults. Example: (defun foo () (let* ((n 2000000) (s (make-string n))) (loop for i from 0 to (1- n) do (setf (elt s i) #\x)) (error s))) (foo) MY ENVIRONMENT: uname -a says: Linux genome 2.4.18 #5 SMP Tue Jul 9 13:58:25 EDT 2002 i686 unknown CLISP CVS head as of June 29, 2005 Built with: ./configure --with-readline --with-dynamic-ffi --with-dynamic-modules --with-module=wildcard --with-module=bindings/glibc --with-module=oracle --with-module=fastcgi --build mysrc with CC set to "gcc -g" ... I did not use --with-debug -------------------------------------------- Backtrace is Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 10630)] 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 6713 unpack_sstring_alloca(*chararray_,len,start, charptr=); (gdb) bt 10 #0 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 #1 0x080cf12f in write_sstring_ab (stream_=0x407a46cc, string=0x1e85d3, start=2000339, len=555261790) at io.d:5117 #2 0x080d914c in write_string_up () at io.d:10542 #3 0x080d918b in C_write_line () at io.d:10553 #4 0x0808f9e3 in eval_subr (fun=0x81d8576) at eval.d:3557 #5 0x0808e50f in eval1 (form=0xbfffb7b0) at eval.d:3033 #6 0x0808f487 in eval (form=0x68026a82) at eval.d:2907 #7 0x08098309 in C_multiple_value_prog1 () at control.d:1755 #8 0x0808e387 in eval1 (form=0xbfffb960) at eval.d:3194 #9 0x0808f487 in eval (form=0x6802694a) at eval.d:2907 (More stack frames follow...) (gdb) ---------------------------------------------------------------------- clisp --version gives GNU CLISP 2.33.83 (2005-03-14) (built 3329226746) (memory 3329378927) Software: GNU C 3.4.4 gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type - Wmissing-declarations -Wno-sign-compare -O2 -fexpensive- optimizations -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES - DNO_SIGSEGV -I. -x none libcharset.a libavcall.a libcallback.a - lreadline -lncurses -ldl -L/usr/X11R6/lib -lX11 SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY Features: (REGEXP SYSCALLS LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX) Installation directory: /usr/local/lib/clisp/ User language: ENGLISH Machine: I686 (I686) genome.hpw.pri.bms.com [140.176.178.197] hin@genome /h/hin/otb> --------------------------------------------------------------------------- gcc -v gives Reading specs from /h/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/specs Configured with: /h/pkg/gcc-3.4.4/configure Thread model: posix gcc version 3.4.4 ------------------------------------------------ /lib/libc.so.6 gives GNU C Library stable release version 2.2.5, by Roland McGrath et al. Copyright (C) 1992-2001, 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. Compiled by GNU CC version 2.95.4 20011002 (Debian prerelease). Compiled on a Linux 2.4.18 system on 2005-01-07. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.9 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Report bugs using the `glibcbug' script to <bu...@gn...>. hin@genome /h/pkg/clisp/mysrc> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 |
From: SourceForge.net <no...@so...> - 2005-07-05 14:04:26
|
Bugs item #1231762, was opened at 2005-07-03 07:42 Message generated for change (Comment added) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: segfault Status: Open Resolution: None Priority: 5 Submitted By: John Hinsdale (hin) >Assigned to: Bruno Haible (haible) Summary: (ERROR large-string) gives seg fault Initial Comment: When I call ERROR with a large message, CLISP seg. faults. Example: (defun foo () (let* ((n 2000000) (s (make-string n))) (loop for i from 0 to (1- n) do (setf (elt s i) #\x)) (error s))) (foo) MY ENVIRONMENT: uname -a says: Linux genome 2.4.18 #5 SMP Tue Jul 9 13:58:25 EDT 2002 i686 unknown CLISP CVS head as of June 29, 2005 Built with: ./configure --with-readline --with-dynamic-ffi --with-dynamic-modules --with-module=wildcard --with-module=bindings/glibc --with-module=oracle --with-module=fastcgi --build mysrc with CC set to "gcc -g" ... I did not use --with-debug -------------------------------------------- Backtrace is Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 10630)] 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 6713 unpack_sstring_alloca(*chararray_,len,start, charptr=); (gdb) bt 10 #0 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 #1 0x080cf12f in write_sstring_ab (stream_=0x407a46cc, string=0x1e85d3, start=2000339, len=555261790) at io.d:5117 #2 0x080d914c in write_string_up () at io.d:10542 #3 0x080d918b in C_write_line () at io.d:10553 #4 0x0808f9e3 in eval_subr (fun=0x81d8576) at eval.d:3557 #5 0x0808e50f in eval1 (form=0xbfffb7b0) at eval.d:3033 #6 0x0808f487 in eval (form=0x68026a82) at eval.d:2907 #7 0x08098309 in C_multiple_value_prog1 () at control.d:1755 #8 0x0808e387 in eval1 (form=0xbfffb960) at eval.d:3194 #9 0x0808f487 in eval (form=0x6802694a) at eval.d:2907 (More stack frames follow...) (gdb) ---------------------------------------------------------------------- clisp --version gives GNU CLISP 2.33.83 (2005-03-14) (built 3329226746) (memory 3329378927) Software: GNU C 3.4.4 gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type - Wmissing-declarations -Wno-sign-compare -O2 -fexpensive- optimizations -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES - DNO_SIGSEGV -I. -x none libcharset.a libavcall.a libcallback.a - lreadline -lncurses -ldl -L/usr/X11R6/lib -lX11 SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY Features: (REGEXP SYSCALLS LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX) Installation directory: /usr/local/lib/clisp/ User language: ENGLISH Machine: I686 (I686) genome.hpw.pri.bms.com [140.176.178.197] hin@genome /h/hin/otb> --------------------------------------------------------------------------- gcc -v gives Reading specs from /h/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/specs Configured with: /h/pkg/gcc-3.4.4/configure Thread model: posix gcc version 3.4.4 ------------------------------------------------ /lib/libc.so.6 gives GNU C Library stable release version 2.2.5, by Roland McGrath et al. Copyright (C) 1992-2001, 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. Compiled by GNU CC version 2.95.4 20011002 (Debian prerelease). Compiled on a Linux 2.4.18 system on 2005-01-07. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.9 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Report bugs using the `glibcbug' script to <bu...@gn...>. hin@genome /h/pkg/clisp/mysrc> ---------------------------------------------------------------------- >Comment By: Sam Steingold (sds) Date: 2005-07-05 10:04 Message: Logged In: YES user_id=5735 the crash is in unpack_sstring_alloca: you cannot allocate more than something like 1k on the C stack using alloca(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 |
From: SourceForge.net <no...@so...> - 2005-07-05 14:29:35
|
Bugs item #1231762, was opened at 2005-07-03 07:42 Message generated for change (Comment added) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: segfault Status: Open Resolution: None Priority: 5 Submitted By: John Hinsdale (hin) Assigned to: Bruno Haible (haible) Summary: (ERROR large-string) gives seg fault Initial Comment: When I call ERROR with a large message, CLISP seg. faults. Example: (defun foo () (let* ((n 2000000) (s (make-string n))) (loop for i from 0 to (1- n) do (setf (elt s i) #\x)) (error s))) (foo) MY ENVIRONMENT: uname -a says: Linux genome 2.4.18 #5 SMP Tue Jul 9 13:58:25 EDT 2002 i686 unknown CLISP CVS head as of June 29, 2005 Built with: ./configure --with-readline --with-dynamic-ffi --with-dynamic-modules --with-module=wildcard --with-module=bindings/glibc --with-module=oracle --with-module=fastcgi --build mysrc with CC set to "gcc -g" ... I did not use --with-debug -------------------------------------------- Backtrace is Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 10630)] 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 6713 unpack_sstring_alloca(*chararray_,len,start, charptr=); (gdb) bt 10 #0 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 #1 0x080cf12f in write_sstring_ab (stream_=0x407a46cc, string=0x1e85d3, start=2000339, len=555261790) at io.d:5117 #2 0x080d914c in write_string_up () at io.d:10542 #3 0x080d918b in C_write_line () at io.d:10553 #4 0x0808f9e3 in eval_subr (fun=0x81d8576) at eval.d:3557 #5 0x0808e50f in eval1 (form=0xbfffb7b0) at eval.d:3033 #6 0x0808f487 in eval (form=0x68026a82) at eval.d:2907 #7 0x08098309 in C_multiple_value_prog1 () at control.d:1755 #8 0x0808e387 in eval1 (form=0xbfffb960) at eval.d:3194 #9 0x0808f487 in eval (form=0x6802694a) at eval.d:2907 (More stack frames follow...) (gdb) ---------------------------------------------------------------------- clisp --version gives GNU CLISP 2.33.83 (2005-03-14) (built 3329226746) (memory 3329378927) Software: GNU C 3.4.4 gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type - Wmissing-declarations -Wno-sign-compare -O2 -fexpensive- optimizations -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES - DNO_SIGSEGV -I. -x none libcharset.a libavcall.a libcallback.a - lreadline -lncurses -ldl -L/usr/X11R6/lib -lX11 SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY Features: (REGEXP SYSCALLS LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX) Installation directory: /usr/local/lib/clisp/ User language: ENGLISH Machine: I686 (I686) genome.hpw.pri.bms.com [140.176.178.197] hin@genome /h/hin/otb> --------------------------------------------------------------------------- gcc -v gives Reading specs from /h/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/specs Configured with: /h/pkg/gcc-3.4.4/configure Thread model: posix gcc version 3.4.4 ------------------------------------------------ /lib/libc.so.6 gives GNU C Library stable release version 2.2.5, by Roland McGrath et al. Copyright (C) 1992-2001, 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. Compiled by GNU CC version 2.95.4 20011002 (Debian prerelease). Compiled on a Linux 2.4.18 system on 2005-01-07. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.9 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Report bugs using the `glibcbug' script to <bu...@gn...>. hin@genome /h/pkg/clisp/mysrc> ---------------------------------------------------------------------- >Comment By: Sam Steingold (sds) Date: 2005-07-05 10:29 Message: Logged In: YES user_id=5735 one solution would be to do chunking: 1. determine the alloca limit in configure 2. replace unpack_sstring_alloca with with_sstring_unpacked 3. make the body thereof iterate over the chunks. this is a lot of work: all callers of unpack_sstring_alloca and with_string have to be modified. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 10:04 Message: Logged In: YES user_id=5735 the crash is in unpack_sstring_alloca: you cannot allocate more than something like 1k on the C stack using alloca(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 |
From: SourceForge.net <no...@so...> - 2005-07-05 14:31:22
|
Bugs item #1231762, was opened at 2005-07-03 07:42 Message generated for change (Comment added) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: segfault Status: Open Resolution: None Priority: 5 Submitted By: John Hinsdale (hin) Assigned to: Bruno Haible (haible) Summary: (ERROR large-string) gives seg fault Initial Comment: When I call ERROR with a large message, CLISP seg. faults. Example: (defun foo () (let* ((n 2000000) (s (make-string n))) (loop for i from 0 to (1- n) do (setf (elt s i) #\x)) (error s))) (foo) MY ENVIRONMENT: uname -a says: Linux genome 2.4.18 #5 SMP Tue Jul 9 13:58:25 EDT 2002 i686 unknown CLISP CVS head as of June 29, 2005 Built with: ./configure --with-readline --with-dynamic-ffi --with-dynamic-modules --with-module=wildcard --with-module=bindings/glibc --with-module=oracle --with-module=fastcgi --build mysrc with CC set to "gcc -g" ... I did not use --with-debug -------------------------------------------- Backtrace is Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 10630)] 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 6713 unpack_sstring_alloca(*chararray_,len,start, charptr=); (gdb) bt 10 #0 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 #1 0x080cf12f in write_sstring_ab (stream_=0x407a46cc, string=0x1e85d3, start=2000339, len=555261790) at io.d:5117 #2 0x080d914c in write_string_up () at io.d:10542 #3 0x080d918b in C_write_line () at io.d:10553 #4 0x0808f9e3 in eval_subr (fun=0x81d8576) at eval.d:3557 #5 0x0808e50f in eval1 (form=0xbfffb7b0) at eval.d:3033 #6 0x0808f487 in eval (form=0x68026a82) at eval.d:2907 #7 0x08098309 in C_multiple_value_prog1 () at control.d:1755 #8 0x0808e387 in eval1 (form=0xbfffb960) at eval.d:3194 #9 0x0808f487 in eval (form=0x6802694a) at eval.d:2907 (More stack frames follow...) (gdb) ---------------------------------------------------------------------- clisp --version gives GNU CLISP 2.33.83 (2005-03-14) (built 3329226746) (memory 3329378927) Software: GNU C 3.4.4 gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type - Wmissing-declarations -Wno-sign-compare -O2 -fexpensive- optimizations -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES - DNO_SIGSEGV -I. -x none libcharset.a libavcall.a libcallback.a - lreadline -lncurses -ldl -L/usr/X11R6/lib -lX11 SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY Features: (REGEXP SYSCALLS LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX) Installation directory: /usr/local/lib/clisp/ User language: ENGLISH Machine: I686 (I686) genome.hpw.pri.bms.com [140.176.178.197] hin@genome /h/hin/otb> --------------------------------------------------------------------------- gcc -v gives Reading specs from /h/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/specs Configured with: /h/pkg/gcc-3.4.4/configure Thread model: posix gcc version 3.4.4 ------------------------------------------------ /lib/libc.so.6 gives GNU C Library stable release version 2.2.5, by Roland McGrath et al. Copyright (C) 1992-2001, 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. Compiled by GNU CC version 2.95.4 20011002 (Debian prerelease). Compiled on a Linux 2.4.18 system on 2005-01-07. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.9 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Report bugs using the `glibcbug' script to <bu...@gn...>. hin@genome /h/pkg/clisp/mysrc> ---------------------------------------------------------------------- >Comment By: Sam Steingold (sds) Date: 2005-07-05 10:31 Message: Logged In: YES user_id=5735 another option is use malloc instead of alloca when the size exceeds ALLOCA_MAX. this also requires replacing unpack_... with with_unpacked_... to accommodate releasing malloc()ed memory. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 10:29 Message: Logged In: YES user_id=5735 one solution would be to do chunking: 1. determine the alloca limit in configure 2. replace unpack_sstring_alloca with with_sstring_unpacked 3. make the body thereof iterate over the chunks. this is a lot of work: all callers of unpack_sstring_alloca and with_string have to be modified. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 10:04 Message: Logged In: YES user_id=5735 the crash is in unpack_sstring_alloca: you cannot allocate more than something like 1k on the C stack using alloca(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 |
From: SourceForge.net <no...@so...> - 2005-07-08 17:11:52
|
Bugs item #1231762, was opened at 2005-07-03 13:42 Message generated for change (Comment added) made by hoehle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: segfault Status: Open Resolution: None Priority: 5 Submitted By: John Hinsdale (hin) Assigned to: Bruno Haible (haible) Summary: (ERROR large-string) gives seg fault Initial Comment: When I call ERROR with a large message, CLISP seg. faults. Example: (defun foo () (let* ((n 2000000) (s (make-string n))) (loop for i from 0 to (1- n) do (setf (elt s i) #\x)) (error s))) (foo) MY ENVIRONMENT: uname -a says: Linux genome 2.4.18 #5 SMP Tue Jul 9 13:58:25 EDT 2002 i686 unknown CLISP CVS head as of June 29, 2005 Built with: ./configure --with-readline --with-dynamic-ffi --with-dynamic-modules --with-module=wildcard --with-module=bindings/glibc --with-module=oracle --with-module=fastcgi --build mysrc with CC set to "gcc -g" ... I did not use --with-debug -------------------------------------------- Backtrace is Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 10630)] 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 6713 unpack_sstring_alloca(*chararray_,len,start, charptr=); (gdb) bt 10 #0 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 #1 0x080cf12f in write_sstring_ab (stream_=0x407a46cc, string=0x1e85d3, start=2000339, len=555261790) at io.d:5117 #2 0x080d914c in write_string_up () at io.d:10542 #3 0x080d918b in C_write_line () at io.d:10553 #4 0x0808f9e3 in eval_subr (fun=0x81d8576) at eval.d:3557 #5 0x0808e50f in eval1 (form=0xbfffb7b0) at eval.d:3033 #6 0x0808f487 in eval (form=0x68026a82) at eval.d:2907 #7 0x08098309 in C_multiple_value_prog1 () at control.d:1755 #8 0x0808e387 in eval1 (form=0xbfffb960) at eval.d:3194 #9 0x0808f487 in eval (form=0x6802694a) at eval.d:2907 (More stack frames follow...) (gdb) ---------------------------------------------------------------------- clisp --version gives GNU CLISP 2.33.83 (2005-03-14) (built 3329226746) (memory 3329378927) Software: GNU C 3.4.4 gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type - Wmissing-declarations -Wno-sign-compare -O2 -fexpensive- optimizations -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES - DNO_SIGSEGV -I. -x none libcharset.a libavcall.a libcallback.a - lreadline -lncurses -ldl -L/usr/X11R6/lib -lX11 SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY Features: (REGEXP SYSCALLS LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX) Installation directory: /usr/local/lib/clisp/ User language: ENGLISH Machine: I686 (I686) genome.hpw.pri.bms.com [140.176.178.197] hin@genome /h/hin/otb> --------------------------------------------------------------------------- gcc -v gives Reading specs from /h/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/specs Configured with: /h/pkg/gcc-3.4.4/configure Thread model: posix gcc version 3.4.4 ------------------------------------------------ /lib/libc.so.6 gives GNU C Library stable release version 2.2.5, by Roland McGrath et al. Copyright (C) 1992-2001, 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. Compiled by GNU CC version 2.95.4 20011002 (Debian prerelease). Compiled on a Linux 2.4.18 system on 2005-01-07. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.9 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Report bugs using the `glibcbug' script to <bu...@gn...>. hin@genome /h/pkg/clisp/mysrc> ---------------------------------------------------------------------- >Comment By: Jörg Höhle (hoehle) Date: 2005-07-08 19:11 Message: Logged In: YES user_id=377168 I'm pretty sure I already did alloca(1MB) (via ffi:with-foreign-string, or via any FFI CALL-OUT mechanism where you pass a C-STRING. If there's really a problem I think what's needed it to touch the C stack in probably ~4KB increments so the OS knows that it has grown and prepares more pages. But that really should be alloca()'s job. It's probably time to file a bug report to the compiler & C library provider instead of CLISP. I put my hand to fire that there's a gazillion SW packages around that use alloca for more than 1KB! I mean, either provide alloca() and assume responsibility, or stay wimpy with the chicken. I'm really surprised this causes a problem on UNIX. GNU diff allocates a lot on the stack (or at least used to do so), and my typical job when porting to the Amiga (around 1990) was to turn some of these into malloc(), so GNU diff was happy with the typical default 4KB stack. IMHO, string management in CLISP shall not use malloc(). ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 16:31 Message: Logged In: YES user_id=5735 another option is use malloc instead of alloca when the size exceeds ALLOCA_MAX. this also requires replacing unpack_... with with_unpacked_... to accommodate releasing malloc()ed memory. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 16:29 Message: Logged In: YES user_id=5735 one solution would be to do chunking: 1. determine the alloca limit in configure 2. replace unpack_sstring_alloca with with_sstring_unpacked 3. make the body thereof iterate over the chunks. this is a lot of work: all callers of unpack_sstring_alloca and with_string have to be modified. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 16:04 Message: Logged In: YES user_id=5735 the crash is in unpack_sstring_alloca: you cannot allocate more than something like 1k on the C stack using alloca(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 |
From: SourceForge.net <no...@so...> - 2005-07-08 17:57:52
|
Bugs item #1231762, was opened at 2005-07-03 07:42 Message generated for change (Comment added) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: segfault Status: Open Resolution: None Priority: 5 Submitted By: John Hinsdale (hin) Assigned to: Bruno Haible (haible) Summary: (ERROR large-string) gives seg fault Initial Comment: When I call ERROR with a large message, CLISP seg. faults. Example: (defun foo () (let* ((n 2000000) (s (make-string n))) (loop for i from 0 to (1- n) do (setf (elt s i) #\x)) (error s))) (foo) MY ENVIRONMENT: uname -a says: Linux genome 2.4.18 #5 SMP Tue Jul 9 13:58:25 EDT 2002 i686 unknown CLISP CVS head as of June 29, 2005 Built with: ./configure --with-readline --with-dynamic-ffi --with-dynamic-modules --with-module=wildcard --with-module=bindings/glibc --with-module=oracle --with-module=fastcgi --build mysrc with CC set to "gcc -g" ... I did not use --with-debug -------------------------------------------- Backtrace is Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 10630)] 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 6713 unpack_sstring_alloca(*chararray_,len,start, charptr=); (gdb) bt 10 #0 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 #1 0x080cf12f in write_sstring_ab (stream_=0x407a46cc, string=0x1e85d3, start=2000339, len=555261790) at io.d:5117 #2 0x080d914c in write_string_up () at io.d:10542 #3 0x080d918b in C_write_line () at io.d:10553 #4 0x0808f9e3 in eval_subr (fun=0x81d8576) at eval.d:3557 #5 0x0808e50f in eval1 (form=0xbfffb7b0) at eval.d:3033 #6 0x0808f487 in eval (form=0x68026a82) at eval.d:2907 #7 0x08098309 in C_multiple_value_prog1 () at control.d:1755 #8 0x0808e387 in eval1 (form=0xbfffb960) at eval.d:3194 #9 0x0808f487 in eval (form=0x6802694a) at eval.d:2907 (More stack frames follow...) (gdb) ---------------------------------------------------------------------- clisp --version gives GNU CLISP 2.33.83 (2005-03-14) (built 3329226746) (memory 3329378927) Software: GNU C 3.4.4 gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type - Wmissing-declarations -Wno-sign-compare -O2 -fexpensive- optimizations -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES - DNO_SIGSEGV -I. -x none libcharset.a libavcall.a libcallback.a - lreadline -lncurses -ldl -L/usr/X11R6/lib -lX11 SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY Features: (REGEXP SYSCALLS LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX) Installation directory: /usr/local/lib/clisp/ User language: ENGLISH Machine: I686 (I686) genome.hpw.pri.bms.com [140.176.178.197] hin@genome /h/hin/otb> --------------------------------------------------------------------------- gcc -v gives Reading specs from /h/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/specs Configured with: /h/pkg/gcc-3.4.4/configure Thread model: posix gcc version 3.4.4 ------------------------------------------------ /lib/libc.so.6 gives GNU C Library stable release version 2.2.5, by Roland McGrath et al. Copyright (C) 1992-2001, 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. Compiled by GNU CC version 2.95.4 20011002 (Debian prerelease). Compiled on a Linux 2.4.18 system on 2005-01-07. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.9 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Report bugs using the `glibcbug' script to <bu...@gn...>. hin@genome /h/pkg/clisp/mysrc> ---------------------------------------------------------------------- >Comment By: Sam Steingold (sds) Date: 2005-07-08 13:57 Message: Logged In: YES user_id=5735 nevertheless, I do get a crash on cygwin in alloca(8000000): Program received signal SIGSEGV, Segmentation fault. 0x005366a3 in probe () (gdb) up #1 0x0004afa9 in ?? () (gdb) #2 0x00460818 in wr_ch_array_unbuffered_dos (stream_=0x101035d4, chararray_=0x101035d0, start=0, len=2000000) at stream.d:5580 5580 var chart* _unpacked_ = (chart*)alloca((len)*sizeof(chart)); (gdb) p len $1 = 2000000 (gdb) p sizeof(chart) $2 = 4 (gdb) p (len)*sizeof(chart) $3 = 8000000 (gdb) note that John uses gcc 3.4.4 with glibc compiled by gcc 2.95 (linux) I also use gcc 3.4.4 on cygwin. when I do the same with gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8), I do not observe the bug. I think this is therefore a gcc 3.4.4 bug. Can someone check what other version of gcc exhibit this behavior? do we need to add a configure check for broken alloca? ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2005-07-08 13:11 Message: Logged In: YES user_id=377168 I'm pretty sure I already did alloca(1MB) (via ffi:with-foreign-string, or via any FFI CALL-OUT mechanism where you pass a C-STRING. If there's really a problem I think what's needed it to touch the C stack in probably ~4KB increments so the OS knows that it has grown and prepares more pages. But that really should be alloca()'s job. It's probably time to file a bug report to the compiler & C library provider instead of CLISP. I put my hand to fire that there's a gazillion SW packages around that use alloca for more than 1KB! I mean, either provide alloca() and assume responsibility, or stay wimpy with the chicken. I'm really surprised this causes a problem on UNIX. GNU diff allocates a lot on the stack (or at least used to do so), and my typical job when porting to the Amiga (around 1990) was to turn some of these into malloc(), so GNU diff was happy with the typical default 4KB stack. IMHO, string management in CLISP shall not use malloc(). ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 10:31 Message: Logged In: YES user_id=5735 another option is use malloc instead of alloca when the size exceeds ALLOCA_MAX. this also requires replacing unpack_... with with_unpacked_... to accommodate releasing malloc()ed memory. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 10:29 Message: Logged In: YES user_id=5735 one solution would be to do chunking: 1. determine the alloca limit in configure 2. replace unpack_sstring_alloca with with_sstring_unpacked 3. make the body thereof iterate over the chunks. this is a lot of work: all callers of unpack_sstring_alloca and with_string have to be modified. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 10:04 Message: Logged In: YES user_id=5735 the crash is in unpack_sstring_alloca: you cannot allocate more than something like 1k on the C stack using alloca(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 |
From: SourceForge.net <no...@so...> - 2005-07-12 16:56:28
|
Bugs item #1231762, was opened at 2005-07-03 13:42 Message generated for change (Comment added) made by hoehle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: segfault Status: Open Resolution: None Priority: 5 Submitted By: John Hinsdale (hin) Assigned to: Bruno Haible (haible) Summary: (ERROR large-string) gives seg fault Initial Comment: When I call ERROR with a large message, CLISP seg. faults. Example: (defun foo () (let* ((n 2000000) (s (make-string n))) (loop for i from 0 to (1- n) do (setf (elt s i) #\x)) (error s))) (foo) MY ENVIRONMENT: uname -a says: Linux genome 2.4.18 #5 SMP Tue Jul 9 13:58:25 EDT 2002 i686 unknown CLISP CVS head as of June 29, 2005 Built with: ./configure --with-readline --with-dynamic-ffi --with-dynamic-modules --with-module=wildcard --with-module=bindings/glibc --with-module=oracle --with-module=fastcgi --build mysrc with CC set to "gcc -g" ... I did not use --with-debug -------------------------------------------- Backtrace is Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 10630)] 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 6713 unpack_sstring_alloca(*chararray_,len,start, charptr=); (gdb) bt 10 #0 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 #1 0x080cf12f in write_sstring_ab (stream_=0x407a46cc, string=0x1e85d3, start=2000339, len=555261790) at io.d:5117 #2 0x080d914c in write_string_up () at io.d:10542 #3 0x080d918b in C_write_line () at io.d:10553 #4 0x0808f9e3 in eval_subr (fun=0x81d8576) at eval.d:3557 #5 0x0808e50f in eval1 (form=0xbfffb7b0) at eval.d:3033 #6 0x0808f487 in eval (form=0x68026a82) at eval.d:2907 #7 0x08098309 in C_multiple_value_prog1 () at control.d:1755 #8 0x0808e387 in eval1 (form=0xbfffb960) at eval.d:3194 #9 0x0808f487 in eval (form=0x6802694a) at eval.d:2907 (More stack frames follow...) (gdb) ---------------------------------------------------------------------- clisp --version gives GNU CLISP 2.33.83 (2005-03-14) (built 3329226746) (memory 3329378927) Software: GNU C 3.4.4 gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type - Wmissing-declarations -Wno-sign-compare -O2 -fexpensive- optimizations -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES - DNO_SIGSEGV -I. -x none libcharset.a libavcall.a libcallback.a - lreadline -lncurses -ldl -L/usr/X11R6/lib -lX11 SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY Features: (REGEXP SYSCALLS LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX) Installation directory: /usr/local/lib/clisp/ User language: ENGLISH Machine: I686 (I686) genome.hpw.pri.bms.com [140.176.178.197] hin@genome /h/hin/otb> --------------------------------------------------------------------------- gcc -v gives Reading specs from /h/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/specs Configured with: /h/pkg/gcc-3.4.4/configure Thread model: posix gcc version 3.4.4 ------------------------------------------------ /lib/libc.so.6 gives GNU C Library stable release version 2.2.5, by Roland McGrath et al. Copyright (C) 1992-2001, 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. Compiled by GNU CC version 2.95.4 20011002 (Debian prerelease). Compiled on a Linux 2.4.18 system on 2005-01-07. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.9 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Report bugs using the `glibcbug' script to <bu...@gn...>. hin@genome /h/pkg/clisp/mysrc> ---------------------------------------------------------------------- >Comment By: Jörg Höhle (hoehle) Date: 2005-07-12 18:56 Message: Logged In: YES user_id=377168 Do you have a simple test case (out of CLISP)? Does the clisp test case depend on the dotimes setf array loop, or does (error(make-string 2000000)) crash as well? What about a backward loop? What about (ignore-errors (foo)), i.e. it looks like PRINT or some such is crashing, how is ERROR really involved? I'll check on my Ubuntu box (gcc 3.3 default, 3.4 available) as soon as I can (hopefully this week). >this also requires replacing unpack_... with with_unpacked_... >to accommodate releasing malloc()ed memory. That would leak memory since AFAIK anything can happen in such a section (call arbitrary code, raise arbitrary exception). LispWorks (and Corman?) have an interesting feature of freeing all allocate-foreign memory within a dynamic extent. That's incompatible (at odds) with FFI :malloc-free declarations, though. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-08 19:57 Message: Logged In: YES user_id=5735 nevertheless, I do get a crash on cygwin in alloca(8000000): Program received signal SIGSEGV, Segmentation fault. 0x005366a3 in probe () (gdb) up #1 0x0004afa9 in ?? () (gdb) #2 0x00460818 in wr_ch_array_unbuffered_dos (stream_=0x101035d4, chararray_=0x101035d0, start=0, len=2000000) at stream.d:5580 5580 var chart* _unpacked_ = (chart*)alloca((len)*sizeof(chart)); (gdb) p len $1 = 2000000 (gdb) p sizeof(chart) $2 = 4 (gdb) p (len)*sizeof(chart) $3 = 8000000 (gdb) note that John uses gcc 3.4.4 with glibc compiled by gcc 2.95 (linux) I also use gcc 3.4.4 on cygwin. when I do the same with gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8), I do not observe the bug. I think this is therefore a gcc 3.4.4 bug. Can someone check what other version of gcc exhibit this behavior? do we need to add a configure check for broken alloca? ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2005-07-08 19:11 Message: Logged In: YES user_id=377168 I'm pretty sure I already did alloca(1MB) (via ffi:with-foreign-string, or via any FFI CALL-OUT mechanism where you pass a C-STRING. If there's really a problem I think what's needed it to touch the C stack in probably ~4KB increments so the OS knows that it has grown and prepares more pages. But that really should be alloca()'s job. It's probably time to file a bug report to the compiler & C library provider instead of CLISP. I put my hand to fire that there's a gazillion SW packages around that use alloca for more than 1KB! I mean, either provide alloca() and assume responsibility, or stay wimpy with the chicken. I'm really surprised this causes a problem on UNIX. GNU diff allocates a lot on the stack (or at least used to do so), and my typical job when porting to the Amiga (around 1990) was to turn some of these into malloc(), so GNU diff was happy with the typical default 4KB stack. IMHO, string management in CLISP shall not use malloc(). ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 16:31 Message: Logged In: YES user_id=5735 another option is use malloc instead of alloca when the size exceeds ALLOCA_MAX. this also requires replacing unpack_... with with_unpacked_... to accommodate releasing malloc()ed memory. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 16:29 Message: Logged In: YES user_id=5735 one solution would be to do chunking: 1. determine the alloca limit in configure 2. replace unpack_sstring_alloca with with_sstring_unpacked 3. make the body thereof iterate over the chunks. this is a lot of work: all callers of unpack_sstring_alloca and with_string have to be modified. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 16:04 Message: Logged In: YES user_id=5735 the crash is in unpack_sstring_alloca: you cannot allocate more than something like 1k on the C stack using alloca(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 |
From: SourceForge.net <no...@so...> - 2005-07-12 17:35:17
|
Bugs item #1231762, was opened at 2005-07-03 07:42 Message generated for change (Comment added) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: segfault Status: Open Resolution: None Priority: 5 Submitted By: John Hinsdale (hin) Assigned to: Bruno Haible (haible) Summary: (ERROR large-string) gives seg fault Initial Comment: When I call ERROR with a large message, CLISP seg. faults. Example: (defun foo () (let* ((n 2000000) (s (make-string n))) (loop for i from 0 to (1- n) do (setf (elt s i) #\x)) (error s))) (foo) MY ENVIRONMENT: uname -a says: Linux genome 2.4.18 #5 SMP Tue Jul 9 13:58:25 EDT 2002 i686 unknown CLISP CVS head as of June 29, 2005 Built with: ./configure --with-readline --with-dynamic-ffi --with-dynamic-modules --with-module=wildcard --with-module=bindings/glibc --with-module=oracle --with-module=fastcgi --build mysrc with CC set to "gcc -g" ... I did not use --with-debug -------------------------------------------- Backtrace is Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 10630)] 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 6713 unpack_sstring_alloca(*chararray_,len,start, charptr=); (gdb) bt 10 #0 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 #1 0x080cf12f in write_sstring_ab (stream_=0x407a46cc, string=0x1e85d3, start=2000339, len=555261790) at io.d:5117 #2 0x080d914c in write_string_up () at io.d:10542 #3 0x080d918b in C_write_line () at io.d:10553 #4 0x0808f9e3 in eval_subr (fun=0x81d8576) at eval.d:3557 #5 0x0808e50f in eval1 (form=0xbfffb7b0) at eval.d:3033 #6 0x0808f487 in eval (form=0x68026a82) at eval.d:2907 #7 0x08098309 in C_multiple_value_prog1 () at control.d:1755 #8 0x0808e387 in eval1 (form=0xbfffb960) at eval.d:3194 #9 0x0808f487 in eval (form=0x6802694a) at eval.d:2907 (More stack frames follow...) (gdb) ---------------------------------------------------------------------- clisp --version gives GNU CLISP 2.33.83 (2005-03-14) (built 3329226746) (memory 3329378927) Software: GNU C 3.4.4 gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type - Wmissing-declarations -Wno-sign-compare -O2 -fexpensive- optimizations -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES - DNO_SIGSEGV -I. -x none libcharset.a libavcall.a libcallback.a - lreadline -lncurses -ldl -L/usr/X11R6/lib -lX11 SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY Features: (REGEXP SYSCALLS LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX) Installation directory: /usr/local/lib/clisp/ User language: ENGLISH Machine: I686 (I686) genome.hpw.pri.bms.com [140.176.178.197] hin@genome /h/hin/otb> --------------------------------------------------------------------------- gcc -v gives Reading specs from /h/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/specs Configured with: /h/pkg/gcc-3.4.4/configure Thread model: posix gcc version 3.4.4 ------------------------------------------------ /lib/libc.so.6 gives GNU C Library stable release version 2.2.5, by Roland McGrath et al. Copyright (C) 1992-2001, 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. Compiled by GNU CC version 2.95.4 20011002 (Debian prerelease). Compiled on a Linux 2.4.18 system on 2005-01-07. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.9 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Report bugs using the `glibcbug' script to <bu...@gn...>. hin@genome /h/pkg/clisp/mysrc> ---------------------------------------------------------------------- >Comment By: Sam Steingold (sds) Date: 2005-07-12 13:35 Message: Logged In: YES user_id=5735 [1]> (error (make-string 2000000 :initial-element #\a)) *** - *** - Program stack overflow. RESET [2]> (ignore-errors (error (make-string 2000000 :initial-element #\a))) Segmentation fault (core dumped) ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2005-07-12 12:56 Message: Logged In: YES user_id=377168 Do you have a simple test case (out of CLISP)? Does the clisp test case depend on the dotimes setf array loop, or does (error(make-string 2000000)) crash as well? What about a backward loop? What about (ignore-errors (foo)), i.e. it looks like PRINT or some such is crashing, how is ERROR really involved? I'll check on my Ubuntu box (gcc 3.3 default, 3.4 available) as soon as I can (hopefully this week). >this also requires replacing unpack_... with with_unpacked_... >to accommodate releasing malloc()ed memory. That would leak memory since AFAIK anything can happen in such a section (call arbitrary code, raise arbitrary exception). LispWorks (and Corman?) have an interesting feature of freeing all allocate-foreign memory within a dynamic extent. That's incompatible (at odds) with FFI :malloc-free declarations, though. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-08 13:57 Message: Logged In: YES user_id=5735 nevertheless, I do get a crash on cygwin in alloca(8000000): Program received signal SIGSEGV, Segmentation fault. 0x005366a3 in probe () (gdb) up #1 0x0004afa9 in ?? () (gdb) #2 0x00460818 in wr_ch_array_unbuffered_dos (stream_=0x101035d4, chararray_=0x101035d0, start=0, len=2000000) at stream.d:5580 5580 var chart* _unpacked_ = (chart*)alloca((len)*sizeof(chart)); (gdb) p len $1 = 2000000 (gdb) p sizeof(chart) $2 = 4 (gdb) p (len)*sizeof(chart) $3 = 8000000 (gdb) note that John uses gcc 3.4.4 with glibc compiled by gcc 2.95 (linux) I also use gcc 3.4.4 on cygwin. when I do the same with gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8), I do not observe the bug. I think this is therefore a gcc 3.4.4 bug. Can someone check what other version of gcc exhibit this behavior? do we need to add a configure check for broken alloca? ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2005-07-08 13:11 Message: Logged In: YES user_id=377168 I'm pretty sure I already did alloca(1MB) (via ffi:with-foreign-string, or via any FFI CALL-OUT mechanism where you pass a C-STRING. If there's really a problem I think what's needed it to touch the C stack in probably ~4KB increments so the OS knows that it has grown and prepares more pages. But that really should be alloca()'s job. It's probably time to file a bug report to the compiler & C library provider instead of CLISP. I put my hand to fire that there's a gazillion SW packages around that use alloca for more than 1KB! I mean, either provide alloca() and assume responsibility, or stay wimpy with the chicken. I'm really surprised this causes a problem on UNIX. GNU diff allocates a lot on the stack (or at least used to do so), and my typical job when porting to the Amiga (around 1990) was to turn some of these into malloc(), so GNU diff was happy with the typical default 4KB stack. IMHO, string management in CLISP shall not use malloc(). ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 10:31 Message: Logged In: YES user_id=5735 another option is use malloc instead of alloca when the size exceeds ALLOCA_MAX. this also requires replacing unpack_... with with_unpacked_... to accommodate releasing malloc()ed memory. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 10:29 Message: Logged In: YES user_id=5735 one solution would be to do chunking: 1. determine the alloca limit in configure 2. replace unpack_sstring_alloca with with_sstring_unpacked 3. make the body thereof iterate over the chunks. this is a lot of work: all callers of unpack_sstring_alloca and with_string have to be modified. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 10:04 Message: Logged In: YES user_id=5735 the crash is in unpack_sstring_alloca: you cannot allocate more than something like 1k on the C stack using alloca(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 |
From: SourceForge.net <no...@so...> - 2005-07-13 09:41:56
|
Bugs item #1231762, was opened at 2005-07-03 13:42 Message generated for change (Comment added) made by hoehle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: segfault Status: Open Resolution: None Priority: 5 Submitted By: John Hinsdale (hin) Assigned to: Bruno Haible (haible) Summary: (ERROR large-string) gives seg fault Initial Comment: When I call ERROR with a large message, CLISP seg. faults. Example: (defun foo () (let* ((n 2000000) (s (make-string n))) (loop for i from 0 to (1- n) do (setf (elt s i) #\x)) (error s))) (foo) MY ENVIRONMENT: uname -a says: Linux genome 2.4.18 #5 SMP Tue Jul 9 13:58:25 EDT 2002 i686 unknown CLISP CVS head as of June 29, 2005 Built with: ./configure --with-readline --with-dynamic-ffi --with-dynamic-modules --with-module=wildcard --with-module=bindings/glibc --with-module=oracle --with-module=fastcgi --build mysrc with CC set to "gcc -g" ... I did not use --with-debug -------------------------------------------- Backtrace is Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 10630)] 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 6713 unpack_sstring_alloca(*chararray_,len,start, charptr=); (gdb) bt 10 #0 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 #1 0x080cf12f in write_sstring_ab (stream_=0x407a46cc, string=0x1e85d3, start=2000339, len=555261790) at io.d:5117 #2 0x080d914c in write_string_up () at io.d:10542 #3 0x080d918b in C_write_line () at io.d:10553 #4 0x0808f9e3 in eval_subr (fun=0x81d8576) at eval.d:3557 #5 0x0808e50f in eval1 (form=0xbfffb7b0) at eval.d:3033 #6 0x0808f487 in eval (form=0x68026a82) at eval.d:2907 #7 0x08098309 in C_multiple_value_prog1 () at control.d:1755 #8 0x0808e387 in eval1 (form=0xbfffb960) at eval.d:3194 #9 0x0808f487 in eval (form=0x6802694a) at eval.d:2907 (More stack frames follow...) (gdb) ---------------------------------------------------------------------- clisp --version gives GNU CLISP 2.33.83 (2005-03-14) (built 3329226746) (memory 3329378927) Software: GNU C 3.4.4 gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type - Wmissing-declarations -Wno-sign-compare -O2 -fexpensive- optimizations -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES - DNO_SIGSEGV -I. -x none libcharset.a libavcall.a libcallback.a - lreadline -lncurses -ldl -L/usr/X11R6/lib -lX11 SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY Features: (REGEXP SYSCALLS LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX) Installation directory: /usr/local/lib/clisp/ User language: ENGLISH Machine: I686 (I686) genome.hpw.pri.bms.com [140.176.178.197] hin@genome /h/hin/otb> --------------------------------------------------------------------------- gcc -v gives Reading specs from /h/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/specs Configured with: /h/pkg/gcc-3.4.4/configure Thread model: posix gcc version 3.4.4 ------------------------------------------------ /lib/libc.so.6 gives GNU C Library stable release version 2.2.5, by Roland McGrath et al. Copyright (C) 1992-2001, 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. Compiled by GNU CC version 2.95.4 20011002 (Debian prerelease). Compiled on a Linux 2.4.18 system on 2005-01-07. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.9 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Report bugs using the `glibcbug' script to <bu...@gn...>. hin@genome /h/pkg/clisp/mysrc> ---------------------------------------------------------------------- >Comment By: Jörg Höhle (hoehle) Date: 2005-07-13 11:41 Message: Logged In: YES user_id=377168 Thanks I forgot that CLISP itself would preinitialize the whole string anyway with #\Null or NIL, so backward Lisp loop does not make sense. My Ubuntu laptop's HD died yesterday, still under warranty, so all tests will have to wait. It might be that the core dump you see on the second attempt is a result of Bug [#1180386]: clisp is in a broken state after the program stack overflow, in some versions. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-12 19:35 Message: Logged In: YES user_id=5735 [1]> (error (make-string 2000000 :initial-element #\a)) *** - *** - Program stack overflow. RESET [2]> (ignore-errors (error (make-string 2000000 :initial-element #\a))) Segmentation fault (core dumped) ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2005-07-12 18:56 Message: Logged In: YES user_id=377168 Do you have a simple test case (out of CLISP)? Does the clisp test case depend on the dotimes setf array loop, or does (error(make-string 2000000)) crash as well? What about a backward loop? What about (ignore-errors (foo)), i.e. it looks like PRINT or some such is crashing, how is ERROR really involved? I'll check on my Ubuntu box (gcc 3.3 default, 3.4 available) as soon as I can (hopefully this week). >this also requires replacing unpack_... with with_unpacked_... >to accommodate releasing malloc()ed memory. That would leak memory since AFAIK anything can happen in such a section (call arbitrary code, raise arbitrary exception). LispWorks (and Corman?) have an interesting feature of freeing all allocate-foreign memory within a dynamic extent. That's incompatible (at odds) with FFI :malloc-free declarations, though. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-08 19:57 Message: Logged In: YES user_id=5735 nevertheless, I do get a crash on cygwin in alloca(8000000): Program received signal SIGSEGV, Segmentation fault. 0x005366a3 in probe () (gdb) up #1 0x0004afa9 in ?? () (gdb) #2 0x00460818 in wr_ch_array_unbuffered_dos (stream_=0x101035d4, chararray_=0x101035d0, start=0, len=2000000) at stream.d:5580 5580 var chart* _unpacked_ = (chart*)alloca((len)*sizeof(chart)); (gdb) p len $1 = 2000000 (gdb) p sizeof(chart) $2 = 4 (gdb) p (len)*sizeof(chart) $3 = 8000000 (gdb) note that John uses gcc 3.4.4 with glibc compiled by gcc 2.95 (linux) I also use gcc 3.4.4 on cygwin. when I do the same with gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8), I do not observe the bug. I think this is therefore a gcc 3.4.4 bug. Can someone check what other version of gcc exhibit this behavior? do we need to add a configure check for broken alloca? ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2005-07-08 19:11 Message: Logged In: YES user_id=377168 I'm pretty sure I already did alloca(1MB) (via ffi:with-foreign-string, or via any FFI CALL-OUT mechanism where you pass a C-STRING. If there's really a problem I think what's needed it to touch the C stack in probably ~4KB increments so the OS knows that it has grown and prepares more pages. But that really should be alloca()'s job. It's probably time to file a bug report to the compiler & C library provider instead of CLISP. I put my hand to fire that there's a gazillion SW packages around that use alloca for more than 1KB! I mean, either provide alloca() and assume responsibility, or stay wimpy with the chicken. I'm really surprised this causes a problem on UNIX. GNU diff allocates a lot on the stack (or at least used to do so), and my typical job when porting to the Amiga (around 1990) was to turn some of these into malloc(), so GNU diff was happy with the typical default 4KB stack. IMHO, string management in CLISP shall not use malloc(). ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 16:31 Message: Logged In: YES user_id=5735 another option is use malloc instead of alloca when the size exceeds ALLOCA_MAX. this also requires replacing unpack_... with with_unpacked_... to accommodate releasing malloc()ed memory. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 16:29 Message: Logged In: YES user_id=5735 one solution would be to do chunking: 1. determine the alloca limit in configure 2. replace unpack_sstring_alloca with with_sstring_unpacked 3. make the body thereof iterate over the chunks. this is a lot of work: all callers of unpack_sstring_alloca and with_string have to be modified. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 16:04 Message: Logged In: YES user_id=5735 the crash is in unpack_sstring_alloca: you cannot allocate more than something like 1k on the C stack using alloca(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 |
From: SourceForge.net <no...@so...> - 2006-03-13 09:55:50
|
Bugs item #1231762, was opened at 2005-07-03 13:42 Message generated for change (Comment added) made by hoehle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: segfault Status: Open Resolution: None Priority: 5 Submitted By: John Hinsdale (hin) Assigned to: Bruno Haible (haible) Summary: (ERROR large-string) gives seg fault Initial Comment: When I call ERROR with a large message, CLISP seg. faults. Example: (defun foo () (let* ((n 2000000) (s (make-string n))) (loop for i from 0 to (1- n) do (setf (elt s i) #\x)) (error s))) (foo) MY ENVIRONMENT: uname -a says: Linux genome 2.4.18 #5 SMP Tue Jul 9 13:58:25 EDT 2002 i686 unknown CLISP CVS head as of June 29, 2005 Built with: ./configure \ --with-readline \ --with-dynamic-ffi \ --with-dynamic-modules \ --with-module=wildcard \ --with-module=bindings/glibc \ --with-module=oracle \ --with-module=fastcgi \ --build mysrc with CC set to "gcc -g" ... I did not use --with-debug -------------------------------------------- Backtrace is Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 10630)] 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 6713 unpack_sstring_alloca(*chararray_,len,start, charptr=); (gdb) bt 10 #0 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 #1 0x080cf12f in write_sstring_ab (stream_=0x407a46cc, string=0x1e85d3, start=2000339, len=555261790) at io.d:5117 #2 0x080d914c in write_string_up () at io.d:10542 #3 0x080d918b in C_write_line () at io.d:10553 #4 0x0808f9e3 in eval_subr (fun=0x81d8576) at eval.d:3557 #5 0x0808e50f in eval1 (form=0xbfffb7b0) at eval.d:3033 #6 0x0808f487 in eval (form=0x68026a82) at eval.d:2907 #7 0x08098309 in C_multiple_value_prog1 () at control.d:1755 #8 0x0808e387 in eval1 (form=0xbfffb960) at eval.d:3194 #9 0x0808f487 in eval (form=0x6802694a) at eval.d:2907 (More stack frames follow...) (gdb) ---------------------------------------------------------------------- clisp --version gives GNU CLISP 2.33.83 (2005-03-14) (built 3329226746) (memory 3329378927) Software: GNU C 3.4.4 gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type - Wmissing-declarations -Wno-sign-compare -O2 -fexpensive- optimizations -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES - DNO_SIGSEGV -I. -x none libcharset.a libavcall.a libcallback.a - lreadline -lncurses -ldl -L/usr/X11R6/lib -lX11 SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY Features: (REGEXP SYSCALLS LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX) Installation directory: /usr/local/lib/clisp/ User language: ENGLISH Machine: I686 (I686) genome.hpw.pri.bms.com [140.176.178.197] hin@genome /h/hin/otb> --------------------------------------------------------------------------- gcc -v gives Reading specs from /h/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/specs Configured with: /h/pkg/gcc-3.4.4/configure Thread model: posix gcc version 3.4.4 ------------------------------------------------ /lib/libc.so.6 gives GNU C Library stable release version 2.2.5, by Roland McGrath et al. Copyright (C) 1992-2001, 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. Compiled by GNU CC version 2.95.4 20011002 (Debian prerelease). Compiled on a Linux 2.4.18 system on 2005-01-07. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.9 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Report bugs using the `glibcbug' script to <bu...@gn...>. hin@genome /h/pkg/clisp/mysrc> ---------------------------------------------------------------------- >Comment By: Jörg Höhle (hoehle) Date: 2006-03-13 10:55 Message: Logged In: YES user_id=377168 I cannot reproduce this. Neither with o Ubuntu/Debian Breezy clisp-2.35 o Ubuntu/Debian Breezy clisp-2.38-CVS with gcc-4.0.2 o Ubuntu/Debian Breezy clisp-2.38-CVS with gcc-3.4 The error message gets displayed! The MS-VC6 2.38-cvs build does not crash either: [10]> (foo) *** - [after some time] *** - Program stack overflow. RESET [after a little more time] [11]> (foo) ;again same behaviour, no core dump. John, I note that your version was built without libsigsegv. Program stack overflows are likely deadly (even with libsigsegv). Do you have evidence that your program stack is large enough that this testcase should not crash? What does ulimit -s report ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2005-07-13 11:41 Message: Logged In: YES user_id=377168 Thanks I forgot that CLISP itself would preinitialize the whole string anyway with #\Null or NIL, so backward Lisp loop does not make sense. My Ubuntu laptop's HD died yesterday, still under warranty, so all tests will have to wait. It might be that the core dump you see on the second attempt is a result of Bug [#1180386]: clisp is in a broken state after the program stack overflow, in some versions. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-12 19:35 Message: Logged In: YES user_id=5735 [1]> (error (make-string 2000000 :initial-element #\a)) *** - *** - Program stack overflow. RESET [2]> (ignore-errors (error (make-string 2000000 :initial-element #\a))) Segmentation fault (core dumped) ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2005-07-12 18:56 Message: Logged In: YES user_id=377168 Do you have a simple test case (out of CLISP)? Does the clisp test case depend on the dotimes setf array loop, or does (error(make-string 2000000)) crash as well? What about a backward loop? What about (ignore-errors (foo)), i.e. it looks like PRINT or some such is crashing, how is ERROR really involved? I'll check on my Ubuntu box (gcc 3.3 default, 3.4 available) as soon as I can (hopefully this week). >this also requires replacing unpack_... with with_unpacked_... >to accommodate releasing malloc()ed memory. That would leak memory since AFAIK anything can happen in such a section (call arbitrary code, raise arbitrary exception). LispWorks (and Corman?) have an interesting feature of freeing all allocate-foreign memory within a dynamic extent. That's incompatible (at odds) with FFI :malloc-free declarations, though. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-08 19:57 Message: Logged In: YES user_id=5735 nevertheless, I do get a crash on cygwin in alloca(8000000): Program received signal SIGSEGV, Segmentation fault. 0x005366a3 in probe () (gdb) up #1 0x0004afa9 in ?? () (gdb) #2 0x00460818 in wr_ch_array_unbuffered_dos (stream_=0x101035d4, chararray_=0x101035d0, start=0, len=2000000) at stream.d:5580 5580 var chart* _unpacked_ = (chart*)alloca((len)*sizeof(chart)); (gdb) p len $1 = 2000000 (gdb) p sizeof(chart) $2 = 4 (gdb) p (len)*sizeof(chart) $3 = 8000000 (gdb) note that John uses gcc 3.4.4 with glibc compiled by gcc 2.95 (linux) I also use gcc 3.4.4 on cygwin. when I do the same with gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8), I do not observe the bug. I think this is therefore a gcc 3.4.4 bug. Can someone check what other version of gcc exhibit this behavior? do we need to add a configure check for broken alloca? ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2005-07-08 19:11 Message: Logged In: YES user_id=377168 I'm pretty sure I already did alloca(1MB) (via ffi:with-foreign-string, or via any FFI CALL-OUT mechanism where you pass a C-STRING. If there's really a problem I think what's needed it to touch the C stack in probably ~4KB increments so the OS knows that it has grown and prepares more pages. But that really should be alloca()'s job. It's probably time to file a bug report to the compiler & C library provider instead of CLISP. I put my hand to fire that there's a gazillion SW packages around that use alloca for more than 1KB! I mean, either provide alloca() and assume responsibility, or stay wimpy with the chicken. I'm really surprised this causes a problem on UNIX. GNU diff allocates a lot on the stack (or at least used to do so), and my typical job when porting to the Amiga (around 1990) was to turn some of these into malloc(), so GNU diff was happy with the typical default 4KB stack. IMHO, string management in CLISP shall not use malloc(). ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 16:31 Message: Logged In: YES user_id=5735 another option is use malloc instead of alloca when the size exceeds ALLOCA_MAX. this also requires replacing unpack_... with with_unpacked_... to accommodate releasing malloc()ed memory. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 16:29 Message: Logged In: YES user_id=5735 one solution would be to do chunking: 1. determine the alloca limit in configure 2. replace unpack_sstring_alloca with with_sstring_unpacked 3. make the body thereof iterate over the chunks. this is a lot of work: all callers of unpack_sstring_alloca and with_string have to be modified. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 16:04 Message: Logged In: YES user_id=5735 the crash is in unpack_sstring_alloca: you cannot allocate more than something like 1k on the C stack using alloca(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 |
From: SourceForge.net <no...@so...> - 2006-03-24 17:13:35
|
Bugs item #1231762, was opened at 2005-07-03 13:42 Message generated for change (Comment added) made by hoehle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: segfault Status: Open Resolution: None Priority: 5 Submitted By: John Hinsdale (hin) Assigned to: Bruno Haible (haible) Summary: (ERROR large-string) gives seg fault Initial Comment: When I call ERROR with a large message, CLISP seg. faults. Example: (defun foo () (let* ((n 2000000) (s (make-string n))) (loop for i from 0 to (1- n) do (setf (elt s i) #\x)) (error s))) (foo) MY ENVIRONMENT: uname -a says: Linux genome 2.4.18 #5 SMP Tue Jul 9 13:58:25 EDT 2002 i686 unknown CLISP CVS head as of June 29, 2005 Built with: ./configure \ --with-readline \ --with-dynamic-ffi \ --with-dynamic-modules \ --with-module=wildcard \ --with-module=bindings/glibc \ --with-module=oracle \ --with-module=fastcgi \ --build mysrc with CC set to "gcc -g" ... I did not use --with-debug -------------------------------------------- Backtrace is Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 10630)] 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 6713 unpack_sstring_alloca(*chararray_,len,start, charptr=); (gdb) bt 10 #0 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 #1 0x080cf12f in write_sstring_ab (stream_=0x407a46cc, string=0x1e85d3, start=2000339, len=555261790) at io.d:5117 #2 0x080d914c in write_string_up () at io.d:10542 #3 0x080d918b in C_write_line () at io.d:10553 #4 0x0808f9e3 in eval_subr (fun=0x81d8576) at eval.d:3557 #5 0x0808e50f in eval1 (form=0xbfffb7b0) at eval.d:3033 #6 0x0808f487 in eval (form=0x68026a82) at eval.d:2907 #7 0x08098309 in C_multiple_value_prog1 () at control.d:1755 #8 0x0808e387 in eval1 (form=0xbfffb960) at eval.d:3194 #9 0x0808f487 in eval (form=0x6802694a) at eval.d:2907 (More stack frames follow...) (gdb) ---------------------------------------------------------------------- clisp --version gives GNU CLISP 2.33.83 (2005-03-14) (built 3329226746) (memory 3329378927) Software: GNU C 3.4.4 gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type - Wmissing-declarations -Wno-sign-compare -O2 -fexpensive- optimizations -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES - DNO_SIGSEGV -I. -x none libcharset.a libavcall.a libcallback.a - lreadline -lncurses -ldl -L/usr/X11R6/lib -lX11 SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY Features: (REGEXP SYSCALLS LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX) Installation directory: /usr/local/lib/clisp/ User language: ENGLISH Machine: I686 (I686) genome.hpw.pri.bms.com [140.176.178.197] hin@genome /h/hin/otb> --------------------------------------------------------------------------- gcc -v gives Reading specs from /h/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/specs Configured with: /h/pkg/gcc-3.4.4/configure Thread model: posix gcc version 3.4.4 ------------------------------------------------ /lib/libc.so.6 gives GNU C Library stable release version 2.2.5, by Roland McGrath et al. Copyright (C) 1992-2001, 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. Compiled by GNU CC version 2.95.4 20011002 (Debian prerelease). Compiled on a Linux 2.4.18 system on 2005-01-07. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.9 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Report bugs using the `glibcbug' script to <bu...@gn...>. hin@genome /h/pkg/clisp/mysrc> ---------------------------------------------------------------------- >Comment By: Jörg Höhle (hoehle) Date: 2006-03-24 18:13 Message: Logged In: YES user_id=377168 >I note that your version was built without libsigsegv. Without libsigsegv, any C program stack overflow is deadly. Sam's observed crash upon second stack overflow is another bug, nr. 1180386. So the bug item should be closed, unless we want to keep it open as a reminder that CLISP could possibly choose another implementation strategy than converting strings on the stack via unpack_sstring_alloca()), which indeed creates problems with huge strings. Doing so would require a serious rewrite of many parts of the code. Note that in a #+UNICODE build, each char takes AFAIK 4bytes, so the example tries to move 8MB on the C stack. ulimit -s on my Debian/Ubuntu box is mere 8192KB... E.g. 2000000 works for me, while 2500000 causes (foo) *** - *** - Program stack overflow. RESET ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-03-13 10:55 Message: Logged In: YES user_id=377168 I cannot reproduce this. Neither with o Ubuntu/Debian Breezy clisp-2.35 o Ubuntu/Debian Breezy clisp-2.38-CVS with gcc-4.0.2 o Ubuntu/Debian Breezy clisp-2.38-CVS with gcc-3.4 The error message gets displayed! The MS-VC6 2.38-cvs build does not crash either: [10]> (foo) *** - [after some time] *** - Program stack overflow. RESET [after a little more time] [11]> (foo) ;again same behaviour, no core dump. John, I note that your version was built without libsigsegv. Program stack overflows are likely deadly (even with libsigsegv). Do you have evidence that your program stack is large enough that this testcase should not crash? What does ulimit -s report ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2005-07-13 11:41 Message: Logged In: YES user_id=377168 Thanks I forgot that CLISP itself would preinitialize the whole string anyway with #\Null or NIL, so backward Lisp loop does not make sense. My Ubuntu laptop's HD died yesterday, still under warranty, so all tests will have to wait. It might be that the core dump you see on the second attempt is a result of Bug [#1180386]: clisp is in a broken state after the program stack overflow, in some versions. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-12 19:35 Message: Logged In: YES user_id=5735 [1]> (error (make-string 2000000 :initial-element #\a)) *** - *** - Program stack overflow. RESET [2]> (ignore-errors (error (make-string 2000000 :initial-element #\a))) Segmentation fault (core dumped) ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2005-07-12 18:56 Message: Logged In: YES user_id=377168 Do you have a simple test case (out of CLISP)? Does the clisp test case depend on the dotimes setf array loop, or does (error(make-string 2000000)) crash as well? What about a backward loop? What about (ignore-errors (foo)), i.e. it looks like PRINT or some such is crashing, how is ERROR really involved? I'll check on my Ubuntu box (gcc 3.3 default, 3.4 available) as soon as I can (hopefully this week). >this also requires replacing unpack_... with with_unpacked_... >to accommodate releasing malloc()ed memory. That would leak memory since AFAIK anything can happen in such a section (call arbitrary code, raise arbitrary exception). LispWorks (and Corman?) have an interesting feature of freeing all allocate-foreign memory within a dynamic extent. That's incompatible (at odds) with FFI :malloc-free declarations, though. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-08 19:57 Message: Logged In: YES user_id=5735 nevertheless, I do get a crash on cygwin in alloca(8000000): Program received signal SIGSEGV, Segmentation fault. 0x005366a3 in probe () (gdb) up #1 0x0004afa9 in ?? () (gdb) #2 0x00460818 in wr_ch_array_unbuffered_dos (stream_=0x101035d4, chararray_=0x101035d0, start=0, len=2000000) at stream.d:5580 5580 var chart* _unpacked_ = (chart*)alloca((len)*sizeof(chart)); (gdb) p len $1 = 2000000 (gdb) p sizeof(chart) $2 = 4 (gdb) p (len)*sizeof(chart) $3 = 8000000 (gdb) note that John uses gcc 3.4.4 with glibc compiled by gcc 2.95 (linux) I also use gcc 3.4.4 on cygwin. when I do the same with gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8), I do not observe the bug. I think this is therefore a gcc 3.4.4 bug. Can someone check what other version of gcc exhibit this behavior? do we need to add a configure check for broken alloca? ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2005-07-08 19:11 Message: Logged In: YES user_id=377168 I'm pretty sure I already did alloca(1MB) (via ffi:with-foreign-string, or via any FFI CALL-OUT mechanism where you pass a C-STRING. If there's really a problem I think what's needed it to touch the C stack in probably ~4KB increments so the OS knows that it has grown and prepares more pages. But that really should be alloca()'s job. It's probably time to file a bug report to the compiler & C library provider instead of CLISP. I put my hand to fire that there's a gazillion SW packages around that use alloca for more than 1KB! I mean, either provide alloca() and assume responsibility, or stay wimpy with the chicken. I'm really surprised this causes a problem on UNIX. GNU diff allocates a lot on the stack (or at least used to do so), and my typical job when porting to the Amiga (around 1990) was to turn some of these into malloc(), so GNU diff was happy with the typical default 4KB stack. IMHO, string management in CLISP shall not use malloc(). ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 16:31 Message: Logged In: YES user_id=5735 another option is use malloc instead of alloca when the size exceeds ALLOCA_MAX. this also requires replacing unpack_... with with_unpacked_... to accommodate releasing malloc()ed memory. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 16:29 Message: Logged In: YES user_id=5735 one solution would be to do chunking: 1. determine the alloca limit in configure 2. replace unpack_sstring_alloca with with_sstring_unpacked 3. make the body thereof iterate over the chunks. this is a lot of work: all callers of unpack_sstring_alloca and with_string have to be modified. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 16:04 Message: Logged In: YES user_id=5735 the crash is in unpack_sstring_alloca: you cannot allocate more than something like 1k on the C stack using alloca(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 |
From: SourceForge.net <no...@so...> - 2006-05-05 13:45:31
|
Bugs item #1231762, was opened at 2005-07-03 13:42 Message generated for change (Settings changed) made by hoehle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: segfault Status: Open >Resolution: Fixed Priority: 5 Submitted By: John Hinsdale (hin) >Assigned to: Jörg Höhle (hoehle) Summary: (ERROR large-string) gives seg fault Initial Comment: When I call ERROR with a large message, CLISP seg. faults. Example: (defun foo () (let* ((n 2000000) (s (make-string n))) (loop for i from 0 to (1- n) do (setf (elt s i) #\x)) (error s))) (foo) MY ENVIRONMENT: uname -a says: Linux genome 2.4.18 #5 SMP Tue Jul 9 13:58:25 EDT 2002 i686 unknown CLISP CVS head as of June 29, 2005 Built with: ./configure \ --with-readline \ --with-dynamic-ffi \ --with-dynamic-modules \ --with-module=wildcard \ --with-module=bindings/glibc \ --with-module=oracle \ --with-module=fastcgi \ --build mysrc with CC set to "gcc -g" ... I did not use --with-debug -------------------------------------------- Backtrace is Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 10630)] 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 6713 unpack_sstring_alloca(*chararray_,len,start, charptr=); (gdb) bt 10 #0 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 #1 0x080cf12f in write_sstring_ab (stream_=0x407a46cc, string=0x1e85d3, start=2000339, len=555261790) at io.d:5117 #2 0x080d914c in write_string_up () at io.d:10542 #3 0x080d918b in C_write_line () at io.d:10553 #4 0x0808f9e3 in eval_subr (fun=0x81d8576) at eval.d:3557 #5 0x0808e50f in eval1 (form=0xbfffb7b0) at eval.d:3033 #6 0x0808f487 in eval (form=0x68026a82) at eval.d:2907 #7 0x08098309 in C_multiple_value_prog1 () at control.d:1755 #8 0x0808e387 in eval1 (form=0xbfffb960) at eval.d:3194 #9 0x0808f487 in eval (form=0x6802694a) at eval.d:2907 (More stack frames follow...) (gdb) ---------------------------------------------------------------------- clisp --version gives GNU CLISP 2.33.83 (2005-03-14) (built 3329226746) (memory 3329378927) Software: GNU C 3.4.4 gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type - Wmissing-declarations -Wno-sign-compare -O2 -fexpensive- optimizations -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES - DNO_SIGSEGV -I. -x none libcharset.a libavcall.a libcallback.a - lreadline -lncurses -ldl -L/usr/X11R6/lib -lX11 SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY Features: (REGEXP SYSCALLS LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX) Installation directory: /usr/local/lib/clisp/ User language: ENGLISH Machine: I686 (I686) genome.hpw.pri.bms.com [140.176.178.197] hin@genome /h/hin/otb> --------------------------------------------------------------------------- gcc -v gives Reading specs from /h/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/specs Configured with: /h/pkg/gcc-3.4.4/configure Thread model: posix gcc version 3.4.4 ------------------------------------------------ /lib/libc.so.6 gives GNU C Library stable release version 2.2.5, by Roland McGrath et al. Copyright (C) 1992-2001, 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. Compiled by GNU CC version 2.95.4 20011002 (Debian prerelease). Compiled on a Linux 2.4.18 system on 2005-01-07. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.9 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Report bugs using the `glibcbug' script to <bu...@gn...>. hin@genome /h/pkg/clisp/mysrc> ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-05-05 15:45 Message: Logged In: YES user_id=377168 thank you for your bug report. the bug has been fixed in the CVS tree. you can either wait for the next release (recommended) or check out the current CVS tree (see http://clisp.cons.org) and build CLISP from the sources (be advised that between releases the CVS tree is very unstable and may not even build on your platform). ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-03-24 18:13 Message: Logged In: YES user_id=377168 >I note that your version was built without libsigsegv. Without libsigsegv, any C program stack overflow is deadly. Sam's observed crash upon second stack overflow is another bug, nr. 1180386. So the bug item should be closed, unless we want to keep it open as a reminder that CLISP could possibly choose another implementation strategy than converting strings on the stack via unpack_sstring_alloca()), which indeed creates problems with huge strings. Doing so would require a serious rewrite of many parts of the code. Note that in a #+UNICODE build, each char takes AFAIK 4bytes, so the example tries to move 8MB on the C stack. ulimit -s on my Debian/Ubuntu box is mere 8192KB... E.g. 2000000 works for me, while 2500000 causes (foo) *** - *** - Program stack overflow. RESET ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-03-13 10:55 Message: Logged In: YES user_id=377168 I cannot reproduce this. Neither with o Ubuntu/Debian Breezy clisp-2.35 o Ubuntu/Debian Breezy clisp-2.38-CVS with gcc-4.0.2 o Ubuntu/Debian Breezy clisp-2.38-CVS with gcc-3.4 The error message gets displayed! The MS-VC6 2.38-cvs build does not crash either: [10]> (foo) *** - [after some time] *** - Program stack overflow. RESET [after a little more time] [11]> (foo) ;again same behaviour, no core dump. John, I note that your version was built without libsigsegv. Program stack overflows are likely deadly (even with libsigsegv). Do you have evidence that your program stack is large enough that this testcase should not crash? What does ulimit -s report ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2005-07-13 11:41 Message: Logged In: YES user_id=377168 Thanks I forgot that CLISP itself would preinitialize the whole string anyway with #\Null or NIL, so backward Lisp loop does not make sense. My Ubuntu laptop's HD died yesterday, still under warranty, so all tests will have to wait. It might be that the core dump you see on the second attempt is a result of Bug [#1180386]: clisp is in a broken state after the program stack overflow, in some versions. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-12 19:35 Message: Logged In: YES user_id=5735 [1]> (error (make-string 2000000 :initial-element #\a)) *** - *** - Program stack overflow. RESET [2]> (ignore-errors (error (make-string 2000000 :initial-element #\a))) Segmentation fault (core dumped) ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2005-07-12 18:56 Message: Logged In: YES user_id=377168 Do you have a simple test case (out of CLISP)? Does the clisp test case depend on the dotimes setf array loop, or does (error(make-string 2000000)) crash as well? What about a backward loop? What about (ignore-errors (foo)), i.e. it looks like PRINT or some such is crashing, how is ERROR really involved? I'll check on my Ubuntu box (gcc 3.3 default, 3.4 available) as soon as I can (hopefully this week). >this also requires replacing unpack_... with with_unpacked_... >to accommodate releasing malloc()ed memory. That would leak memory since AFAIK anything can happen in such a section (call arbitrary code, raise arbitrary exception). LispWorks (and Corman?) have an interesting feature of freeing all allocate-foreign memory within a dynamic extent. That's incompatible (at odds) with FFI :malloc-free declarations, though. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-08 19:57 Message: Logged In: YES user_id=5735 nevertheless, I do get a crash on cygwin in alloca(8000000): Program received signal SIGSEGV, Segmentation fault. 0x005366a3 in probe () (gdb) up #1 0x0004afa9 in ?? () (gdb) #2 0x00460818 in wr_ch_array_unbuffered_dos (stream_=0x101035d4, chararray_=0x101035d0, start=0, len=2000000) at stream.d:5580 5580 var chart* _unpacked_ = (chart*)alloca((len)*sizeof(chart)); (gdb) p len $1 = 2000000 (gdb) p sizeof(chart) $2 = 4 (gdb) p (len)*sizeof(chart) $3 = 8000000 (gdb) note that John uses gcc 3.4.4 with glibc compiled by gcc 2.95 (linux) I also use gcc 3.4.4 on cygwin. when I do the same with gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8), I do not observe the bug. I think this is therefore a gcc 3.4.4 bug. Can someone check what other version of gcc exhibit this behavior? do we need to add a configure check for broken alloca? ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2005-07-08 19:11 Message: Logged In: YES user_id=377168 I'm pretty sure I already did alloca(1MB) (via ffi:with-foreign-string, or via any FFI CALL-OUT mechanism where you pass a C-STRING. If there's really a problem I think what's needed it to touch the C stack in probably ~4KB increments so the OS knows that it has grown and prepares more pages. But that really should be alloca()'s job. It's probably time to file a bug report to the compiler & C library provider instead of CLISP. I put my hand to fire that there's a gazillion SW packages around that use alloca for more than 1KB! I mean, either provide alloca() and assume responsibility, or stay wimpy with the chicken. I'm really surprised this causes a problem on UNIX. GNU diff allocates a lot on the stack (or at least used to do so), and my typical job when porting to the Amiga (around 1990) was to turn some of these into malloc(), so GNU diff was happy with the typical default 4KB stack. IMHO, string management in CLISP shall not use malloc(). ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 16:31 Message: Logged In: YES user_id=5735 another option is use malloc instead of alloca when the size exceeds ALLOCA_MAX. this also requires replacing unpack_... with with_unpacked_... to accommodate releasing malloc()ed memory. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 16:29 Message: Logged In: YES user_id=5735 one solution would be to do chunking: 1. determine the alloca limit in configure 2. replace unpack_sstring_alloca with with_sstring_unpacked 3. make the body thereof iterate over the chunks. this is a lot of work: all callers of unpack_sstring_alloca and with_string have to be modified. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 16:04 Message: Logged In: YES user_id=5735 the crash is in unpack_sstring_alloca: you cannot allocate more than something like 1k on the C stack using alloca(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 |
From: SourceForge.net <no...@so...> - 2006-05-19 19:36:49
|
Bugs item #1231762, was opened at 2005-07-03 05:42 Message generated for change (Comment added) made by junrue You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: segfault Status: Open Resolution: Fixed Priority: 5 Submitted By: John Hinsdale (hin) Assigned to: Jörg Höhle (hoehle) Summary: (ERROR large-string) gives seg fault Initial Comment: When I call ERROR with a large message, CLISP seg. faults. Example: (defun foo () (let* ((n 2000000) (s (make-string n))) (loop for i from 0 to (1- n) do (setf (elt s i) #\x)) (error s))) (foo) MY ENVIRONMENT: uname -a says: Linux genome 2.4.18 #5 SMP Tue Jul 9 13:58:25 EDT 2002 i686 unknown CLISP CVS head as of June 29, 2005 Built with: ./configure \ --with-readline \ --with-dynamic-ffi \ --with-dynamic-modules \ --with-module=wildcard \ --with-module=bindings/glibc \ --with-module=oracle \ --with-module=fastcgi \ --build mysrc with CC set to "gcc -g" ... I did not use --with-debug -------------------------------------------- Backtrace is Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 10630)] 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 6713 unpack_sstring_alloca(*chararray_,len,start, charptr=); (gdb) bt 10 #0 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 #1 0x080cf12f in write_sstring_ab (stream_=0x407a46cc, string=0x1e85d3, start=2000339, len=555261790) at io.d:5117 #2 0x080d914c in write_string_up () at io.d:10542 #3 0x080d918b in C_write_line () at io.d:10553 #4 0x0808f9e3 in eval_subr (fun=0x81d8576) at eval.d:3557 #5 0x0808e50f in eval1 (form=0xbfffb7b0) at eval.d:3033 #6 0x0808f487 in eval (form=0x68026a82) at eval.d:2907 #7 0x08098309 in C_multiple_value_prog1 () at control.d:1755 #8 0x0808e387 in eval1 (form=0xbfffb960) at eval.d:3194 #9 0x0808f487 in eval (form=0x6802694a) at eval.d:2907 (More stack frames follow...) (gdb) ---------------------------------------------------------------------- clisp --version gives GNU CLISP 2.33.83 (2005-03-14) (built 3329226746) (memory 3329378927) Software: GNU C 3.4.4 gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type - Wmissing-declarations -Wno-sign-compare -O2 -fexpensive- optimizations -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES - DNO_SIGSEGV -I. -x none libcharset.a libavcall.a libcallback.a - lreadline -lncurses -ldl -L/usr/X11R6/lib -lX11 SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY Features: (REGEXP SYSCALLS LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX) Installation directory: /usr/local/lib/clisp/ User language: ENGLISH Machine: I686 (I686) genome.hpw.pri.bms.com [140.176.178.197] hin@genome /h/hin/otb> --------------------------------------------------------------------------- gcc -v gives Reading specs from /h/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/specs Configured with: /h/pkg/gcc-3.4.4/configure Thread model: posix gcc version 3.4.4 ------------------------------------------------ /lib/libc.so.6 gives GNU C Library stable release version 2.2.5, by Roland McGrath et al. Copyright (C) 1992-2001, 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. Compiled by GNU CC version 2.95.4 20011002 (Debian prerelease). Compiled on a Linux 2.4.18 system on 2005-01-07. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.9 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Report bugs using the `glibcbug' script to <bu...@gn...>. hin@genome /h/pkg/clisp/mysrc> ---------------------------------------------------------------------- Comment By: Jack D. Unrue (junrue) Date: 2006-05-19 13:36 Message: Logged In: YES user_id=119851 CVS as of Fri May 19 13:36:13 MST 2006 works OK for me. MINGW32_NT-5.1 DRIVEN 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown ./configure --with-mingw --build build-mingw --with-libsigsegv-prefix=/usr/local ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-05-05 07:45 Message: Logged In: YES user_id=377168 thank you for your bug report. the bug has been fixed in the CVS tree. you can either wait for the next release (recommended) or check out the current CVS tree (see http://clisp.cons.org) and build CLISP from the sources (be advised that between releases the CVS tree is very unstable and may not even build on your platform). ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-03-24 10:13 Message: Logged In: YES user_id=377168 >I note that your version was built without libsigsegv. Without libsigsegv, any C program stack overflow is deadly. Sam's observed crash upon second stack overflow is another bug, nr. 1180386. So the bug item should be closed, unless we want to keep it open as a reminder that CLISP could possibly choose another implementation strategy than converting strings on the stack via unpack_sstring_alloca()), which indeed creates problems with huge strings. Doing so would require a serious rewrite of many parts of the code. Note that in a #+UNICODE build, each char takes AFAIK 4bytes, so the example tries to move 8MB on the C stack. ulimit -s on my Debian/Ubuntu box is mere 8192KB... E.g. 2000000 works for me, while 2500000 causes (foo) *** - *** - Program stack overflow. RESET ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-03-13 02:55 Message: Logged In: YES user_id=377168 I cannot reproduce this. Neither with o Ubuntu/Debian Breezy clisp-2.35 o Ubuntu/Debian Breezy clisp-2.38-CVS with gcc-4.0.2 o Ubuntu/Debian Breezy clisp-2.38-CVS with gcc-3.4 The error message gets displayed! The MS-VC6 2.38-cvs build does not crash either: [10]> (foo) *** - [after some time] *** - Program stack overflow. RESET [after a little more time] [11]> (foo) ;again same behaviour, no core dump. John, I note that your version was built without libsigsegv. Program stack overflows are likely deadly (even with libsigsegv). Do you have evidence that your program stack is large enough that this testcase should not crash? What does ulimit -s report ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2005-07-13 03:41 Message: Logged In: YES user_id=377168 Thanks I forgot that CLISP itself would preinitialize the whole string anyway with #\Null or NIL, so backward Lisp loop does not make sense. My Ubuntu laptop's HD died yesterday, still under warranty, so all tests will have to wait. It might be that the core dump you see on the second attempt is a result of Bug [#1180386]: clisp is in a broken state after the program stack overflow, in some versions. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-12 11:35 Message: Logged In: YES user_id=5735 [1]> (error (make-string 2000000 :initial-element #\a)) *** - *** - Program stack overflow. RESET [2]> (ignore-errors (error (make-string 2000000 :initial-element #\a))) Segmentation fault (core dumped) ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2005-07-12 10:56 Message: Logged In: YES user_id=377168 Do you have a simple test case (out of CLISP)? Does the clisp test case depend on the dotimes setf array loop, or does (error(make-string 2000000)) crash as well? What about a backward loop? What about (ignore-errors (foo)), i.e. it looks like PRINT or some such is crashing, how is ERROR really involved? I'll check on my Ubuntu box (gcc 3.3 default, 3.4 available) as soon as I can (hopefully this week). >this also requires replacing unpack_... with with_unpacked_... >to accommodate releasing malloc()ed memory. That would leak memory since AFAIK anything can happen in such a section (call arbitrary code, raise arbitrary exception). LispWorks (and Corman?) have an interesting feature of freeing all allocate-foreign memory within a dynamic extent. That's incompatible (at odds) with FFI :malloc-free declarations, though. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-08 11:57 Message: Logged In: YES user_id=5735 nevertheless, I do get a crash on cygwin in alloca(8000000): Program received signal SIGSEGV, Segmentation fault. 0x005366a3 in probe () (gdb) up #1 0x0004afa9 in ?? () (gdb) #2 0x00460818 in wr_ch_array_unbuffered_dos (stream_=0x101035d4, chararray_=0x101035d0, start=0, len=2000000) at stream.d:5580 5580 var chart* _unpacked_ = (chart*)alloca((len)*sizeof(chart)); (gdb) p len $1 = 2000000 (gdb) p sizeof(chart) $2 = 4 (gdb) p (len)*sizeof(chart) $3 = 8000000 (gdb) note that John uses gcc 3.4.4 with glibc compiled by gcc 2.95 (linux) I also use gcc 3.4.4 on cygwin. when I do the same with gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8), I do not observe the bug. I think this is therefore a gcc 3.4.4 bug. Can someone check what other version of gcc exhibit this behavior? do we need to add a configure check for broken alloca? ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2005-07-08 11:11 Message: Logged In: YES user_id=377168 I'm pretty sure I already did alloca(1MB) (via ffi:with-foreign-string, or via any FFI CALL-OUT mechanism where you pass a C-STRING. If there's really a problem I think what's needed it to touch the C stack in probably ~4KB increments so the OS knows that it has grown and prepares more pages. But that really should be alloca()'s job. It's probably time to file a bug report to the compiler & C library provider instead of CLISP. I put my hand to fire that there's a gazillion SW packages around that use alloca for more than 1KB! I mean, either provide alloca() and assume responsibility, or stay wimpy with the chicken. I'm really surprised this causes a problem on UNIX. GNU diff allocates a lot on the stack (or at least used to do so), and my typical job when porting to the Amiga (around 1990) was to turn some of these into malloc(), so GNU diff was happy with the typical default 4KB stack. IMHO, string management in CLISP shall not use malloc(). ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 08:31 Message: Logged In: YES user_id=5735 another option is use malloc instead of alloca when the size exceeds ALLOCA_MAX. this also requires replacing unpack_... with with_unpacked_... to accommodate releasing malloc()ed memory. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 08:29 Message: Logged In: YES user_id=5735 one solution would be to do chunking: 1. determine the alloca limit in configure 2. replace unpack_sstring_alloca with with_sstring_unpacked 3. make the body thereof iterate over the chunks. this is a lot of work: all callers of unpack_sstring_alloca and with_string have to be modified. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 08:04 Message: Logged In: YES user_id=5735 the crash is in unpack_sstring_alloca: you cannot allocate more than something like 1k on the C stack using alloca(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 |
From: SourceForge.net <no...@so...> - 2006-12-28 20:18:21
|
Bugs item #1231762, was opened at 2005-07-03 07:42 Message generated for change (Settings changed) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: segfault >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: John Hinsdale (hin) Assigned to: Jörg Höhle (hoehle) Summary: (ERROR large-string) gives seg fault Initial Comment: When I call ERROR with a large message, CLISP seg. faults. Example: (defun foo () (let* ((n 2000000) (s (make-string n))) (loop for i from 0 to (1- n) do (setf (elt s i) #\x)) (error s))) (foo) MY ENVIRONMENT: uname -a says: Linux genome 2.4.18 #5 SMP Tue Jul 9 13:58:25 EDT 2002 i686 unknown CLISP CVS head as of June 29, 2005 Built with: ./configure \ --with-readline \ --with-dynamic-ffi \ --with-dynamic-modules \ --with-module=wildcard \ --with-module=bindings/glibc \ --with-module=oracle \ --with-module=fastcgi \ --build mysrc with CC set to "gcc -g" ... I did not use --with-debug -------------------------------------------- Backtrace is Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 10630)] 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 6713 unpack_sstring_alloca(*chararray_,len,start, charptr=); (gdb) bt 10 #0 0x080b3614 in wr_ch_array_buffered_unix (stream_=0x1e85d3, chararray_=0x1e85d3, start=0, len=2000339) at stream.d:6713 #1 0x080cf12f in write_sstring_ab (stream_=0x407a46cc, string=0x1e85d3, start=2000339, len=555261790) at io.d:5117 #2 0x080d914c in write_string_up () at io.d:10542 #3 0x080d918b in C_write_line () at io.d:10553 #4 0x0808f9e3 in eval_subr (fun=0x81d8576) at eval.d:3557 #5 0x0808e50f in eval1 (form=0xbfffb7b0) at eval.d:3033 #6 0x0808f487 in eval (form=0x68026a82) at eval.d:2907 #7 0x08098309 in C_multiple_value_prog1 () at control.d:1755 #8 0x0808e387 in eval1 (form=0xbfffb960) at eval.d:3194 #9 0x0808f487 in eval (form=0x6802694a) at eval.d:2907 (More stack frames follow...) (gdb) ---------------------------------------------------------------------- clisp --version gives GNU CLISP 2.33.83 (2005-03-14) (built 3329226746) (memory 3329378927) Software: GNU C 3.4.4 gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type - Wmissing-declarations -Wno-sign-compare -O2 -fexpensive- optimizations -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES - DNO_SIGSEGV -I. -x none libcharset.a libavcall.a libcallback.a - lreadline -lncurses -ldl -L/usr/X11R6/lib -lX11 SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY Features: (REGEXP SYSCALLS LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX) Installation directory: /usr/local/lib/clisp/ User language: ENGLISH Machine: I686 (I686) genome.hpw.pri.bms.com [140.176.178.197] hin@genome /h/hin/otb> --------------------------------------------------------------------------- gcc -v gives Reading specs from /h/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/specs Configured with: /h/pkg/gcc-3.4.4/configure Thread model: posix gcc version 3.4.4 ------------------------------------------------ /lib/libc.so.6 gives GNU C Library stable release version 2.2.5, by Roland McGrath et al. Copyright (C) 1992-2001, 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. Compiled by GNU CC version 2.95.4 20011002 (Debian prerelease). Compiled on a Linux 2.4.18 system on 2005-01-07. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.9 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Report bugs using the `glibcbug' script to <bu...@gn...>. hin@genome /h/pkg/clisp/mysrc> ---------------------------------------------------------------------- Comment By: Jack D. Unrue (junrue) Date: 2006-05-19 15:36 Message: Logged In: YES user_id=119851 CVS as of Fri May 19 13:36:13 MST 2006 works OK for me. MINGW32_NT-5.1 DRIVEN 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown ./configure --with-mingw --build build-mingw --with-libsigsegv-prefix=/usr/local ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-05-05 09:45 Message: Logged In: YES user_id=377168 thank you for your bug report. the bug has been fixed in the CVS tree. you can either wait for the next release (recommended) or check out the current CVS tree (see http://clisp.cons.org) and build CLISP from the sources (be advised that between releases the CVS tree is very unstable and may not even build on your platform). ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-03-24 12:13 Message: Logged In: YES user_id=377168 >I note that your version was built without libsigsegv. Without libsigsegv, any C program stack overflow is deadly. Sam's observed crash upon second stack overflow is another bug, nr. 1180386. So the bug item should be closed, unless we want to keep it open as a reminder that CLISP could possibly choose another implementation strategy than converting strings on the stack via unpack_sstring_alloca()), which indeed creates problems with huge strings. Doing so would require a serious rewrite of many parts of the code. Note that in a #+UNICODE build, each char takes AFAIK 4bytes, so the example tries to move 8MB on the C stack. ulimit -s on my Debian/Ubuntu box is mere 8192KB... E.g. 2000000 works for me, while 2500000 causes (foo) *** - *** - Program stack overflow. RESET ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2006-03-13 04:55 Message: Logged In: YES user_id=377168 I cannot reproduce this. Neither with o Ubuntu/Debian Breezy clisp-2.35 o Ubuntu/Debian Breezy clisp-2.38-CVS with gcc-4.0.2 o Ubuntu/Debian Breezy clisp-2.38-CVS with gcc-3.4 The error message gets displayed! The MS-VC6 2.38-cvs build does not crash either: [10]> (foo) *** - [after some time] *** - Program stack overflow. RESET [after a little more time] [11]> (foo) ;again same behaviour, no core dump. John, I note that your version was built without libsigsegv. Program stack overflows are likely deadly (even with libsigsegv). Do you have evidence that your program stack is large enough that this testcase should not crash? What does ulimit -s report ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2005-07-13 05:41 Message: Logged In: YES user_id=377168 Thanks I forgot that CLISP itself would preinitialize the whole string anyway with #\Null or NIL, so backward Lisp loop does not make sense. My Ubuntu laptop's HD died yesterday, still under warranty, so all tests will have to wait. It might be that the core dump you see on the second attempt is a result of Bug [#1180386]: clisp is in a broken state after the program stack overflow, in some versions. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-12 13:35 Message: Logged In: YES user_id=5735 [1]> (error (make-string 2000000 :initial-element #\a)) *** - *** - Program stack overflow. RESET [2]> (ignore-errors (error (make-string 2000000 :initial-element #\a))) Segmentation fault (core dumped) ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2005-07-12 12:56 Message: Logged In: YES user_id=377168 Do you have a simple test case (out of CLISP)? Does the clisp test case depend on the dotimes setf array loop, or does (error(make-string 2000000)) crash as well? What about a backward loop? What about (ignore-errors (foo)), i.e. it looks like PRINT or some such is crashing, how is ERROR really involved? I'll check on my Ubuntu box (gcc 3.3 default, 3.4 available) as soon as I can (hopefully this week). >this also requires replacing unpack_... with with_unpacked_... >to accommodate releasing malloc()ed memory. That would leak memory since AFAIK anything can happen in such a section (call arbitrary code, raise arbitrary exception). LispWorks (and Corman?) have an interesting feature of freeing all allocate-foreign memory within a dynamic extent. That's incompatible (at odds) with FFI :malloc-free declarations, though. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-08 13:57 Message: Logged In: YES user_id=5735 nevertheless, I do get a crash on cygwin in alloca(8000000): Program received signal SIGSEGV, Segmentation fault. 0x005366a3 in probe () (gdb) up #1 0x0004afa9 in ?? () (gdb) #2 0x00460818 in wr_ch_array_unbuffered_dos (stream_=0x101035d4, chararray_=0x101035d0, start=0, len=2000000) at stream.d:5580 5580 var chart* _unpacked_ = (chart*)alloca((len)*sizeof(chart)); (gdb) p len $1 = 2000000 (gdb) p sizeof(chart) $2 = 4 (gdb) p (len)*sizeof(chart) $3 = 8000000 (gdb) note that John uses gcc 3.4.4 with glibc compiled by gcc 2.95 (linux) I also use gcc 3.4.4 on cygwin. when I do the same with gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8), I do not observe the bug. I think this is therefore a gcc 3.4.4 bug. Can someone check what other version of gcc exhibit this behavior? do we need to add a configure check for broken alloca? ---------------------------------------------------------------------- Comment By: Jörg Höhle (hoehle) Date: 2005-07-08 13:11 Message: Logged In: YES user_id=377168 I'm pretty sure I already did alloca(1MB) (via ffi:with-foreign-string, or via any FFI CALL-OUT mechanism where you pass a C-STRING. If there's really a problem I think what's needed it to touch the C stack in probably ~4KB increments so the OS knows that it has grown and prepares more pages. But that really should be alloca()'s job. It's probably time to file a bug report to the compiler & C library provider instead of CLISP. I put my hand to fire that there's a gazillion SW packages around that use alloca for more than 1KB! I mean, either provide alloca() and assume responsibility, or stay wimpy with the chicken. I'm really surprised this causes a problem on UNIX. GNU diff allocates a lot on the stack (or at least used to do so), and my typical job when porting to the Amiga (around 1990) was to turn some of these into malloc(), so GNU diff was happy with the typical default 4KB stack. IMHO, string management in CLISP shall not use malloc(). ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 10:31 Message: Logged In: YES user_id=5735 another option is use malloc instead of alloca when the size exceeds ALLOCA_MAX. this also requires replacing unpack_... with with_unpacked_... to accommodate releasing malloc()ed memory. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 10:29 Message: Logged In: YES user_id=5735 one solution would be to do chunking: 1. determine the alloca limit in configure 2. replace unpack_sstring_alloca with with_sstring_unpacked 3. make the body thereof iterate over the chunks. this is a lot of work: all callers of unpack_sstring_alloca and with_string have to be modified. ---------------------------------------------------------------------- Comment By: Sam Steingold (sds) Date: 2005-07-05 10:04 Message: Logged In: YES user_id=5735 the crash is in unpack_sstring_alloca: you cannot allocate more than something like 1k on the C stack using alloca(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1231762&group_id=1355 |