From: Marco G. <mar...@ti...> - 2007-02-22 07:49:25
|
Hi, EXT::LAUNCH seems to be the only way to read stdout *and* stderr of an external program, so I tried it with CLISP 2.38 and it worked nicely. I did not update CLISP for quite a while but recently updated SuSE, got version 2.39 and found that LAUNCH crashed the interpreter. The same happend with the current CVS version (2.41). Debugging of the CLISP sources revealed some strange STACK behaviour in stream.d:mkops_from_handles which I was able to fix with the included patch at the end of this mail. Some comments concerning this patch would be very appreciated since it was more wild guessing and fixing by analogy than anything else. From my C perspective the code should be equivalent, but it makes (at least here) a huge difference. Btw. I wasn't able to build a GC-safety checking version of CLISP as described in http://clisp.cons.org/impnotes/gc-safety.html. The built lisp.run executable which is used to compile the lisp sources immediately crashed with SIGSEGV. (Sorry, but I did not save the stack backtrace) clisp --version: > GNU CLISP 2.41 (2006-10-13) (built 3381077956) (memory 3381078242) > Software: GNU-C 4.1.2 20061115 (prerelease) (SUSE Linux) > gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O -DUNICODE -DDYNAMIC_FFI -I. -L/home/local/lib -x none libcharset.a libavcall.a libcallback.a -lreadline -lncurses -ldl -L/home/local/lib -lsigsegv -lc -R/home/local/lib -L/usr/lib64 > SAFETY=0 TYPECODES WIDE GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY > libsigsegv 2.2 > libreadline 5.1 > Features: > (READLINE REGEXP SYSCALLS I18N 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) > C Modules: (clisp i18n syscalls regexp readline) > Installation directory: /home/local/lib/clisp-2.41/ > User language: ENGLISH > Machine: X86_64 (X86_64) tristan.br-automation.com [127.0.0.2] Regards, Marco Index: src/stream.d =================================================================== RCS file: /cvsroot/clisp/clisp/src/stream.d,v retrieving revision 1.576 diff -u -3 -p -a -u -r1.576 stream.d --- src/stream.d 6 Feb 2007 03:24:48 -0000 1.576 +++ src/stream.d 21 Feb 2007 20:44:48 -0000 @@ -13043,18 +13043,19 @@ global maygc void mkops_from_handles (Ha # Check and canonicalize the :EXTERNAL-FORMAT argument: STACK_2 = test_external_format_arg(STACK_2); STACK_0 = allocate_handle(opipe); + var object stream; if (buffered > 0) { - pushSTACK(make_buffered_stream(strmtype_pipe_out,DIRECTION_OUTPUT, - &eltype,false,false)); - BufferedPipeStream_init(STACK_0); + stream = make_buffered_stream(strmtype_pipe_out,DIRECTION_OUTPUT, + &eltype,false,false); + BufferedPipeStream_init(stream); } else { - pushSTACK(make_unbuffered_stream(strmtype_pipe_out,DIRECTION_OUTPUT, - &eltype,false,false)); - UnbufferedPipeStream_output_init(STACK_0); - } - ChannelStreamLow_close(STACK_0) = &low_close_pipe; - TheStream(STACK_0)->strm_pipe_pid = UL_to_I(process_id); - add_to_open_streams(STACK_0); /* return stream */ + stream = make_unbuffered_stream(strmtype_pipe_out,DIRECTION_OUTPUT, + &eltype,false,false); + UnbufferedPipeStream_output_init(stream); + } + ChannelStreamLow_close(stream) = &low_close_pipe; + TheStream(stream)->strm_pipe_pid = UL_to_I(process_id); + pushSTACK(add_to_open_streams(stream)); /* return stream */ } /* mkips_from_handles(pipe,process_id) @@ -13077,18 +13078,19 @@ global maygc void mkips_from_handles (Ha # Check and canonicalize the :EXTERNAL-FORMAT argument: STACK_2 = test_external_format_arg(STACK_2); STACK_0 = allocate_handle(ipipe); + var object stream; if (buffered >= 0) { - pushSTACK(make_buffered_stream(strmtype_pipe_in,DIRECTION_INPUT, - &eltype,false,false)); - BufferedPipeStream_init(STACK_0); + stream = make_buffered_stream(strmtype_pipe_in,DIRECTION_INPUT, + &eltype,false,false); + BufferedPipeStream_init(stream); } else { - pushSTACK(make_unbuffered_stream(strmtype_pipe_in,DIRECTION_INPUT, - &eltype,false,false)); - UnbufferedPipeStream_input_init(STACK_0); - } - ChannelStreamLow_close(STACK_0) = &low_close_pipe; - TheStream(STACK_0)->strm_pipe_pid = UL_to_I(process_id); - add_to_open_streams(STACK_0); /* return stream */ + stream = make_unbuffered_stream(strmtype_pipe_in,DIRECTION_INPUT, + &eltype,false,false); + UnbufferedPipeStream_input_init(stream); + } + ChannelStreamLow_close(stream) = &low_close_pipe; + TheStream(stream)->strm_pipe_pid = UL_to_I(process_id); + pushSTACK(add_to_open_streams(stream)); /* return stream */ } |
From: Sam S. <sd...@gn...> - 2007-02-22 14:51:23
|
Hi, Marco Gidde wrote: > > EXT::LAUNCH seems to be the only way to read stdout *and* stderr of an > external program, so I tried it with CLISP 2.38 and it worked > nicely. I did not update CLISP for quite a while but recently updated > SuSE, got version 2.39 and found that LAUNCH crashed the > interpreter. The same happend with the current CVS version (2.41). could you please supply a stand-alone test case? > Debugging of the CLISP sources revealed some strange STACK behaviour > in stream.d:mkops_from_handles which I was able to fix with the > included patch at the end of this mail. could you please be more specific? what was strange? > Btw. I wasn't able to build a GC-safety checking version of CLISP as > described in http://clisp.cons.org/impnotes/gc-safety.html. The built WFM. > lisp.run executable which is used to compile the lisp sources > immediately crashed with SIGSEGV. could you please debug it? > diff -u -3 -p -a -u -r1.576 stream.d > --- src/stream.d 6 Feb 2007 03:24:48 -0000 1.576 > +++ src/stream.d 21 Feb 2007 20:44:48 -0000 > - TheStream(STACK_0)->strm_pipe_pid = UL_to_I(process_id); > - add_to_open_streams(STACK_0); /* return stream */ > + TheStream(stream)->strm_pipe_pid = UL_to_I(process_id); > + pushSTACK(add_to_open_streams(stream)); /* return stream */ you cannot do this. 1. UL_to_I maygc ==> RHS must be GC-safe. 2. add_to_open_streams plays with STACK, so it cannot be mixed with pushSTACK in the same statement. |
From: Marco G. <mar...@ti...> - 2007-02-22 17:30:08
|
Sam Steingold <sd...@gn...> writes: > Marco Gidde wrote: >> EXT::LAUNCH seems to be the only way to read stdout *and* stderr of >> an >> external program, so I tried it with CLISP 2.38 and it worked >> nicely. I did not update CLISP for quite a while but recently updated >> SuSE, got version 2.39 and found that LAUNCH crashed the >> interpreter. The same happend with the current CVS version (2.41). > > could you please supply a stand-alone test case? [1]> (ext::launch "ls" :output :pipe) 21024 ; NIL ; #<ENCODING CHARSET:UTF-8 :UNIX> ; NIL [2]> (con<TAB> segmentation fault Instead of an encoding a stream should be returned. After that CLISP is completely mixed up and crashes when trying to get the tab expansion of CON (or anything else). >> Debugging of the CLISP sources revealed some strange STACK behaviour >> in stream.d:mkops_from_handles which I was able to fix with the >> included patch at the end of this mail. > > could you please be more specific? what was strange? The relevant code in stream.d lookes like this: local maygc object make_buffered_stream (uintB type, direction_t direction, const decoded_el_t* eltype, bool handle_regular, bool handle_blockpositioning) { ... # allocate Stream: var object stream = allocate_stream(flags,type,strm_channel_len,xlen); ... skipSTACK(1); return stream; } global maygc void mk[io]ps_from_handles (Handle opipe, int process_id) { ... if (buffered > 0) { pushSTACK(make_buffered_stream(strmtype_pipe_out,DIRECTION_OUTPUT, &eltype,false,false)); BufferedPipeStream_init(STACK_0); } else { ... } make_buffered_stream reads three elements from STACK and returns the stream object. mk[io]ps_from_handles should push this stream on STACK but pushes something else (UNBOUND or the ENCODING above). >> Btw. I wasn't able to build a GC-safety checking version of CLISP as >> described in http://clisp.cons.org/impnotes/gc-safety.html. The built > > WFM. > >> lisp.run executable which is used to compile the lisp sources >> immediately crashed with SIGSEGV. > > could you please debug it? If I find some time. Right now I'm not so keen on it. >> diff -u -3 -p -a -u -r1.576 stream.d >> --- src/stream.d 6 Feb 2007 03:24:48 -0000 1.576 >> +++ src/stream.d 21 Feb 2007 20:44:48 -0000 >> - TheStream(STACK_0)->strm_pipe_pid = UL_to_I(process_id); >> - add_to_open_streams(STACK_0); /* return stream */ >> + TheStream(stream)->strm_pipe_pid = UL_to_I(process_id); >> + pushSTACK(add_to_open_streams(stream)); /* return stream */ > > you cannot do this. > 1. UL_to_I maygc ==> RHS must be GC-safe. Do you mean LHS? If not, what is not GC-safe on the RHS? > 2. add_to_open_streams plays with STACK, so it cannot be mixed with > pushSTACK in the same statement. So 2. also applies to the pushSTACK(make_buffered_stream(...)) statements in mk[io]ps_from_handles? Is there some more verbose explanation of what is allowed and what isn't than impnotes/gc-safety.html? Regards, Marco |
From: Marco G. <mar...@ti...> - 2007-02-23 19:51:31
|
Sam Steingold <sd...@gn...> writes: >> Btw. I wasn't able to build a GC-safety checking version of CLISP as >> described in http://clisp.cons.org/impnotes/gc-safety.html. The built > > WFM. > >> lisp.run executable which is used to compile the lisp sources >> immediately crashed with SIGSEGV. > > could you please debug it? The crash happens quite early: ... (gdb) show args Argument list to give program being debugged when it is started is "-B . -E 1:1 -Efile UTF-8 -Eterminal UTF-8 -norc -m 1800KW". (gdb) bt #0 0x0000000000815eac in with_gc_statistics (fun=0x442940 <do_gar_col_simple>) at lispbibl.d:4179 #1 0x0000000000405048 in gar_col_simple () at spvw_garcol.d:2405 #2 0x000000000040e5c7 in make_space_gc_true (need=72, heapptr=0xbe5a08) at spvw_allocate.d:219 #3 0x0000000000411285 in allocate_vector (len=7) at spvw_typealloc.d:89 #4 0x00000000004112b3 in init_subr_tab_2 () at subrkw.d:7 #5 0x00000000004286f7 in initmem () at spvw.d:1497 #6 0x000000000043f66c in init_memory (p=0xbe6ab0) at spvw.d:2928 #7 0x000000000044709e in main (argc=<value optimized out>, argv=0x7fff9d293be8) at spvw.d:3268 (gdb) p inside_gc $5 = false Feel free to ask for more details if necessary. Regards, Marco |
From: Sam S. <sd...@gn...> - 2007-02-22 21:43:28
|
Marco Gidde wrote: > > [1]> (ext::launch "ls" :output :pipe) > 21024 ; > NIL ; > #<ENCODING CHARSET:UTF-8 :UNIX> ; > NIL > [2]> (con<TAB> segmentation fault > > Instead of an encoding a stream should be returned. After that CLISP > is completely mixed up and crashes when trying to get the tab > expansion of CON (or anything else). should be fixed in the CVS head, thanks. http://sourceforge.net/tracker/index.php?func=detail&aid=1666509&group_id=1355&atid=101355 > So 2. also applies to the pushSTACK(make_buffered_stream(...)) > statements in mk[io]ps_from_handles? Is there some more verbose > explanation of what is allowed and what isn't than > impnotes/gc-safety.html? http://clisp.podval.org/impnotes/gc-safety.html#gc-lisp-in-C |
From: Marco G. <mar...@ti...> - 2007-02-22 23:34:04
|
Sam Steingold <sd...@gn...> writes: > should be fixed in the CVS head, thanks. > http://sourceforge.net/tracker/index.php?func=detail&aid=1666509&group_id=1355&atid=101355 It works now. Thanks! >> So 2. also applies to the pushSTACK(make_buffered_stream(...)) >> statements in mk[io]ps_from_handles? Is there some more verbose >> explanation of what is allowed and what isn't than >> impnotes/gc-safety.html? > > http://clisp.podval.org/impnotes/gc-safety.html#gc-lisp-in-C :-) |
From: Sam S. <sd...@gn...> - 2007-02-23 20:09:32
|
Marco Gidde wrote: > The crash happens quite early: > > ... > (gdb) show args > Argument list to give program being debugged when it is started is "-B . -E 1:1 -Efile UTF-8 -Eterminal UTF-8 -norc -m 1800KW". > (gdb) bt > #0 0x0000000000815eac in with_gc_statistics (fun=0x442940 <do_gar_col_simple>) > at lispbibl.d:4179 > #1 0x0000000000405048 in gar_col_simple () at spvw_garcol.d:2405 > #2 0x000000000040e5c7 in make_space_gc_true (need=72, heapptr=0xbe5a08) > at spvw_allocate.d:219 > #3 0x0000000000411285 in allocate_vector (len=7) at spvw_typealloc.d:89 > #4 0x00000000004112b3 in init_subr_tab_2 () at subrkw.d:7 > #5 0x00000000004286f7 in initmem () at spvw.d:1497 > #6 0x000000000043f66c in init_memory (p=0xbe6ab0) at spvw.d:2928 > #7 0x000000000044709e in main (argc=<value optimized out>, argv=0x7fff9d293be8) > at spvw.d:3268 > (gdb) p inside_gc > $5 = false > > Feel free to ask for more details if necessary. could you please file a separate self-contained bug report on this? http://clisp.cons.org/impnotes/faq.html#faq-bugs http://clisp.cons.org/impnotes/clisp.html#bugs http://sourceforge.net/tracker/?group_id=1355&atid=101355 Thanks, Sam. |
From: Marco G. <mar...@ti...> - 2007-02-24 14:50:12
|
Sam Steingold <sd...@gn...> writes: > could you please file a separate self-contained bug report on this? > http://clisp.cons.org/impnotes/faq.html#faq-bugs > http://clisp.cons.org/impnotes/clisp.html#bugs > http://sourceforge.net/tracker/?group_id=1355&atid=101355 It's the same as http://sourceforge.net/tracker/index.php?func=detail&aid=1385641&group_id=1355&atid=101355 Regards, Marco |
From: Sam S. <sd...@gn...> - 2007-02-25 00:33:21
|
> * Marco Gidde <znepb.tvqqr@gvfpnyv.qr> [2007-02-24 15:49:58 +0100]: > > Sam Steingold <sd...@gn...> writes: >> could you please file a separate self-contained bug report on this? >> http://clisp.cons.org/impnotes/faq.html#faq-bugs >> http://clisp.cons.org/impnotes/clisp.html#bugs >> http://sourceforge.net/tracker/?group_id=1355&atid=101355 > > It's the same as > http://sourceforge.net/tracker/index.php?func=detail&aid=1385641&group_id=1355&atid=101355 what's your platform? amd64 also? -- Sam Steingold (http://sds.podval.org/) on Fedora Core release 6 (Zod) http://jihadwatch.org http://palestinefacts.org http://pmw.org.il http://honestreporting.com http://thereligionofpeace.com http://camera.org Heredity, n: the reason your children are bright. |
From: Marco G. <mar...@ti...> - 2007-02-25 00:41:39
|
Sam Steingold <sd...@gn...> writes: > what's your platform? amd64 also? Yep > cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 28 model name : Mobile AMD Athlon(tm) 64 Processor 3000+ stepping : 0 cpu MHz : 800.000 cache size : 512 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow up lahf_lm bogomips : 1593.49 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp |