From: Vladimir T. <vtz...@gm...> - 2009-01-28 17:05:37
|
Don, Sam, I just committed fix for this: On Wed, Jan 28, 2009 at 4:36 AM, Don Cohen <don...@is...> wrote: > Below is the transcript on a 64 bit machine running linux. ....... > *** - handle_fault error2 ! address = 0xc00000006 not in > [0x334308000,0x334370d38) ! > SIGSEGV cannot be cured. Fault address = 0xc00000006. The problem apeared to be symbol_ structure. it' size was not multiple of varobject_alignment. I have used uintL for tls_index and it is 32 bit on 64 bit platforms as well. I have changed it to be aint (is this the correct type for index?). PS: it's strange since it was uintL for a quite a while and it looked to be fine -so I am not 100% sure that only this is the problem. |
From: <don...@is...> - 2009-01-28 17:23:26
|
Vladimir Tzankov writes: > Don, Sam, > > I just committed fix for this: That helps. I then hit the xthread problem, which I now know how to fix. The make then finishes. make check ends with the now familiar *** - EVAL: undefined function SAVEINITMEM |
From: Vladimir T. <vtz...@gm...> - 2009-01-29 00:16:49
|
On Jan 28, 2009, at 7:23 PM, Don Cohen wrote: > Vladimir Tzankov writes: >> Don, Sam, >> >> I just committed fix for this: > That helps. I then hit the xthread problem, which I now know how to > fix. The make then finishes. make check ends with the now familiar > *** - EVAL: undefined function SAVEINITMEM should be fixed in the cvs. the problem was related to the fact that currently the threads are not "persistent" (do not survive image save/load). per thread symvalues of special variables too. |
From: <don...@is...> - 2009-01-29 00:35:50
|
Vladimir Tzankov writes: > > *** - EVAL: undefined function SAVEINITMEM > should be fixed in the cvs. > the problem was related to the fact that currently the threads are > not "persistent" (do not survive image save/load). > per thread symvalues of special variables too. make check now stalls - I see the load go to zero: EQUAL-OK: (42 NIL) (MULTIPLE-VALUE-BIND (CMD ARGS) (CMD-ARGS) (WITH-OPEN-STREAM (S (MAKE-PIPE-INPUT-STREAM (WITH-OUTPUT-TO-STRING (S) (PRINC CMD S) (DOLIST (A ARGS) (PRINC #\Space S) (PRINC A S)) (PRINC " -x '(quote hello)'" S)))) (READ-LINE S))) [I had not meant to send yet, but this is where it stalled] [the rest of the shell buffer follows] |
From: <don...@is...> - 2009-01-29 00:41:06
|
Vladimir Tzankov writes: > > *** - EVAL: undefined function SAVEINITMEM > should be fixed in the cvs. > the problem was related to the fact that currently the threads are > not "persistent" (do not survive image save/load). > per thread symvalues of special variables too. make check now stalls - I see the load go to zero: EQUAL-OK: (42 NIL) (MULTIPLE-VALUE-BIND (CMD ARGS) (CMD-ARGS) (WITH-OPEN-STREAM (S (MAKE-PIPE-INPUT-STREAM (WITH-OUTPUT-TO-STRING (S) (PRINC CMD S) (DOLIST (A ARGS) (PRINC #\Space S) (PRINC A S)) (PRINC " -x '(quote hello)'" S)))) (READ-LINE S))) [I had not meant to send yet, but this is where it stalled] [the rest of the shell buffer follows] Now I see what happens - I typed some C-C's into the shell buffer to get the attention of the shell. When I copy and paste into the mail buffer those C-C's send the message !! so, after the C-C's: *** - Condition of type SYSTEM::INTERRUPT-CONDITION. Real time: 366.92838 sec. Run time: 46.921867 sec. Space: 1247236816 Bytes GC: 1232, GC time: 9.648571 sec. Bye. make[1]: *** [tests] Error 1 make: *** [check-tests] Interrupt [2009-01-28 16:32:31 root@number11 ~/clisp/build-mt] $ [2009-01-28 16:32:31 root@number11 ~/clisp/build-mt] $ *** - UNIX error 5 (EIO): I/O error *** - UNIX error 5 (EIO): I/O error ===== I then try another make check and get the old error about saveinitmem being undefined - very quickly. I then redo the make (very fast), redo make check and now it takes longer but ends as before with load -> 0 at EQL-OK: T (MULTIPLE-VALUE-BIND (CMD ARGS) (CMD-ARGS) (LIST (RUN-PROGRAM CMD :ARGUMENTS (APPEND ARGS '("-x" "(exit 42)"))) (RUN-PROGRAM CMD :ARGUMENTS (APPEND ARGS '("-x" "(exit)"))))) EQUAL-OK: (42 NIL) (MULTIPLE-VALUE-BIND (CMD ARGS) (CMD-ARGS) (WITH-OPEN-STREAM (S (MAKE-PIPE-INPUT-STREAM (WITH-OUTPUT-TO-STRING (S) (PRINC CMD S) (DOLIST (A ARGS) (PRINC #\Space S) (PRINC A S)) (PRINC " -x '(quote hello)'" S)))) (READ-LINE S))) |
From: Vladimir T. <vtz...@gm...> - 2009-01-30 00:52:11
|
Sam, On Jan 29, 2009, at 2:41 AM, Don Cohen wrote: >>> make check now stalls - I see the load go to zero: > > EQUAL-OK: (42 NIL) > (MULTIPLE-VALUE-BIND (CMD ARGS) (CMD-ARGS) (WITH-OPEN-STREAM (S > (MAKE-PIPE-INPUT-STREAM (WITH-OUTPUT-TO-STRING (S) (PRINC CMD S) > (DOLIST (A ARGS) (PRINC #\Space S) (PRINC A S)) (PRINC " -x '(quote > hello)'" S)))) (READ-LINE S))) > It happens on some linuxes (2.6.18 is fine, 2.6.27 is not). Appears the problem is caused by the SETSID() stream.d:12880 If I comment it - all tests pass (even the others that also pass through SETSID() call). I do not see a reason to create a new process group for the piped process. If we die - it's stdout will be broken (this process may do some other things totally not related to us - but after all we have spawned it). Not sure why it works in single thread builds. There is a remark in: http://www.kernel.org/doc/man-pages/online/pages/man7/pthreads.7.html >> Only the main thread is permitted to start a new session using setsid(2) (fixed in kernel 2.6.16) In MT builds the main thread (main()) is used for signal handling so all tests (and all lisp code) do not execute in it. But I see that it works fine on 2.6.18. Not sure whether to comment it for pipes or #ifdef the SETSID() to do nothing in MT? Vladimir |
From: <don...@is...> - 2009-01-29 00:34:29
|
Vladimir Tzankov writes: > > *** - EVAL: undefined function SAVEINITMEM > should be fixed in the cvs. > the problem was related to the fact that currently the threads are > not "persistent" (do not survive image save/load). > per thread symvalues of special variables too. make check now stalls - I see the load go to zero: EQUAL-OK: (42 NIL) (MULTIPLE-VALUE-BIND (CMD ARGS) (CMD-ARGS) (WITH-OPEN-STREAM (S (MAKE-PIPE-INPUT-STREAM (WITH-OUTPUT-TO-STRING (S) (PRINC CMD S) (DOLIST (A ARGS) (PRINC #\Space S) (PRINC A S)) (PRINC " -x '(quote hello)'" S)))) (READ-LINE S))) |
From: Vladimir T. <vtz...@gm...> - 2009-01-29 00:40:02
|
On Jan 29, 2009, at 2:34 AM, Don Cohen wrote: > Vladimir Tzankov writes: >>> *** - EVAL: undefined function SAVEINITMEM >> should be fixed in the cvs. >> the problem was related to the fact that currently the threads are >> not "persistent" (do not survive image save/load). >> per thread symvalues of special variables too. > make check now stalls - I see the load go to zero: > > EQUAL-OK: (42 NIL) > (MULTIPLE-VALUE-BIND (CMD ARGS) (CMD-ARGS) (WITH-OPEN-STREAM (S > (MAKE-PIPE-INPUT-STREAM (WITH-OUTPUT-TO-STRING (S) (PRINC CMD S) > (DOLIST (A ARGS) (PRINC #\Space S) (PRINC A S)) (PRINC " -x '(quote > hello)'" S)))) (READ-LINE S))) > Are you running it in some virtual machine? I have encountered this behavior under VirtualBox. |
From: <don...@is...> - 2009-01-29 00:43:24
|
Vladimir Tzankov writes: > Are you running it in some virtual machine? > I have encountered this behavior under VirtualBox. I only wish! If you know how to make virtual machines work then we can start another thread. (Can it be done without the special hardware support that is supposed to be turned on in the BIOS but seems not to be known to my BIOS?) |
From: Vladimir T. <vtz...@gm...> - 2009-01-29 00:55:50
|
On Jan 29, 2009, at 2:41 AM, Don Cohen wrote: > Vladimir Tzankov writes: >>> *** - EVAL: undefined function SAVEINITMEM >> should be fixed in the cvs. >> the problem was related to the fact that currently the threads are >> not "persistent" (do not survive image save/load). >> per thread symvalues of special variables too. > make check now stalls - I see the load go to zero: > > EQUAL-OK: (42 NIL) > (MULTIPLE-VALUE-BIND (CMD ARGS) (CMD-ARGS) (WITH-OPEN-STREAM (S > (MAKE-PIPE-INPUT-STREAM (WITH-OUTPUT-TO-STRING (S) (PRINC CMD S) > (DOLIST (A ARGS) (PRINC #\Space S) (PRINC A S)) (PRINC " -x '(quote > hello)'" S)))) (READ-LINE S))) i encountered this problem - bit only when tests are run under some virtual machine. i do not think that problem is with the virtual machine itself. it's on my list. (however when running on 32bit osx and linux (debian etch) - it's fine) > > Now I see what happens - I typed some C-C's into the shell buffer to > get the attention of the shell. When I copy and paste into the mail > buffer those C-C's send the message !! > > so, after the C-C's: > *** - Condition of type SYSTEM::INTERRUPT-CONDITION. > Real time: 366.92838 sec. > Run time: 46.921867 sec. > Space: 1247236816 Bytes > GC: 1232, GC time: 9.648571 sec. > Bye. > make[1]: *** [tests] Error 1 > make: *** [check-tests] Interrupt it's normal - since clisp is run with "-norc". without it you will get a prompt. > ===== > I then try another make check and get the old error about saveinitmem > being undefined - very quickly. > I then redo the make (very fast), redo make check and now it takes > longer but ends as before with load -> 0 at sorry- not sure that i understand this. Is this 64bit build? |
From: <don...@is...> - 2009-01-29 02:35:02
|
Vladimir Tzankov writes: > > I then try another make check and get the old error about saveinitmem > > being undefined - very quickly. > > I then redo the make (very fast), redo make check and now it takes > > longer but ends as before with load -> 0 at > > sorry- not sure that i understand this. ... make[1]: *** [tests] Error 1 make: *** [check-tests] Interrupt [2009-01-28 17:29:11 root@number11 ~/clisp/build-mt] $ [2009-01-28 17:29:11 root@number11 ~/clisp/build-mt] $ *** - UNIX error 5 (EIO): I/O error *** - UNIX error 5 (EIO): I/O error [2009-01-28 17:30:23 root@number11 ~/clisp/build-mt] $ make check ... ./foo -x "(setq zz 10) (saveinitmem \"foo\")" ... WARNING: No installation directory specified. Please try: ./foo -B /usr/local/lib/clisp 10 *** - EVAL: undefined function SAVEINITMEM Bye. ./foo -norc -M foo.mem -x zz ./foo: operating system error during load of initialization file `foo.mem' [../src/spvw_memfile.d:972] errno = ENOENT: No such file or directory. make: *** [check-exec-image] Error 1 [2009-01-28 17:30:41 root@number11 ~/clisp/build-mt] $ make ... $ make check ... EQUAL-OK: (42 NIL) (MULTIPLE-VALUE-BIND (CMD ARGS) (CMD-ARGS) (WITH-OPEN-STREAM (S (MAKE-PIPE-INPUT-STREAM (WITH-OUTPUT-TO-STRING (S) (PRINC CMD S) (DOLIST (A ARGS) (PRINC #\Space S) (PRINC A S)) (PRINC " -x '(quote hello)'" S)))) (READ-LINE S))) ^C > Is this 64bit build? Yes. |
From: Jose A. O. R. <ja...@gn...> - 2009-01-29 09:08:15
|
Vladimir Tzankov <vtz...@gm...> writes: > On Jan 28, 2009, at 7:23 PM, Don Cohen wrote: >> Vladimir Tzankov writes: >>> Don, Sam, >>> >>> I just committed fix for this: >> That helps. I then hit the xthread problem, which I now know how to >> fix. The make then finishes. make check ends with the now familiar >> *** - EVAL: undefined function SAVEINITMEM > > should be fixed in the cvs. > the problem was related to the fact that currently the threads are > not "persistent" (do not survive image save/load). > per thread symvalues of special variables too.the Works for me in 32 bit linux. The only remaining quirk is the already mentioned errors in FORMAT (reproduced below); but those are not specific to the MT build. Thanks, jao --8<---------------cut here---------------start------------->8--- Form: (FORMAT NIL "~G" 9.999999999999999d22) CORRECT: "100000000000000000000000. " CLISP : "100000000000000000000000.0 " Differ at position 25: #\Space vs #\0 CORRECT: " " CLISP : "0 " Form: (FORMAT NIL "~E" 9.999999999999999d22) CORRECT: "1.0d+23" CLISP : "9.999999999999999d+22" Differ at position 0: #\1 vs #\9 CORRECT: "1.0d+23" CLISP : "9.99999999..." --8<---------------cut here---------------end--------------->8--- |
From: Sam S. <sd...@gn...> - 2009-01-30 14:45:38
|
Vladimir, Vladimir Tzankov wrote: > On Jan 29, 2009, at 2:41 AM, Don Cohen wrote: >>>> make check now stalls - I see the load go to zero: >> EQUAL-OK: (42 NIL) >> (MULTIPLE-VALUE-BIND (CMD ARGS) (CMD-ARGS) (WITH-OPEN-STREAM (S >> (MAKE-PIPE-INPUT-STREAM (WITH-OUTPUT-TO-STRING (S) (PRINC CMD S) >> (DOLIST (A ARGS) (PRINC #\Space S) (PRINC A S)) (PRINC " -x '(quote >> hello)'" S)))) (READ-LINE S))) >> > > It happens on some linuxes (2.6.18 is fine, 2.6.27 is not). > Appears the problem is caused by the SETSID() stream.d:12880 > If I comment it - all tests pass (even the others that also pass > through SETSID() call). I do not see a reason to create a new process > group for the piped process. If we die - it's stdout will be broken > (this process may do some other things totally not related to us - > but after all we have spawned it). > > Not sure why it works in single thread builds. There is a remark in: > http://www.kernel.org/doc/man-pages/online/pages/man7/pthreads.7.html > >> Only the main thread is permitted to start a new session using > setsid(2) (fixed in kernel 2.6.16) > In MT builds the main thread (main()) is used for signal handling so > all tests (and all lisp code) do not execute in it. But I see that it > works fine on 2.6.18. this seems to indicate that the bug fixed in 2.6.16 was reintroduced before 27 (but after 18). maybe this should be reported to the kernel maintainers? > Not sure whether to comment it for pipes or #ifdef the SETSID() to do > nothing in MT? I don't know anything about these system calls. if you know what you are doing and are confident that setsid does not serve any useful purpose, you can remove the calls outright (with an extensive explanation in the changelog). otherwise, you could disable it just in MT builds. if you want to be extra careful, you can write an autoconf test to detect whether setsid can be used the way we do, and disable it if it cannot be. Bruno, can you comment on the matter? PS. please do not CC me. I do read clisp lists, always. |
From: Bruno H. <br...@cl...> - 2009-01-30 23:41:11
|
Sam wrote: > > Not sure whether to comment it for pipes or #ifdef the SETSID() to do > > nothing in MT? > > I don't know anything about these system calls. setsid: http://www.opengroup.org/onlinepubs/9699919799/functions/setsid.html setpgrp: http://www.opengroup.org/onlinepubs/9699919799/functions/setpgrp.html setpgid: http://www.opengroup.org/onlinepubs/9699919799/functions/setpgid.html > if you know what you are doing and are confident that setsid does not serve any > useful purpose, you can remove the calls outright (with an extensive > explanation in the changelog). > otherwise, you could disable it just in MT builds. > if you want to be extra careful, you can write an autoconf test to detect > whether setsid can be used the way we do, and disable it if it cannot be. > Bruno, can you comment on the matter? There are situations where you need it, and there are situations where it hurts to have SETSID() called in the freshly created subprocess. Probably I encountered a case where it was needed, years ago, and put in the call, so that things behaved "correctly" w.r.t. Ctrl-C and logout. Maybe this case was that when the user presses Ctrl-C, the user expects to stop clisp's execution, but without the SETSID() the system sends a SIGINT signal to the subprocess, thus killing it. (Because clisp's signal handler for Ctrl-C has no effect on the subprocess.) Bruno |
From: Vladimir T. <vtz...@gm...> - 2009-02-01 09:47:16
|
On Jan 31, 2009, at 1:41 AM, Bruno Haible wrote: > Sam wrote: >> if you know what you are doing and are confident that setsid does >> not serve any >> useful purpose, you can remove the calls outright (with an extensive >> explanation in the changelog). >> otherwise, you could disable it just in MT builds. >> if you want to be extra careful, you can write an autoconf test to >> detect >> whether setsid can be used the way we do, and disable it if it >> cannot be. >> Bruno, can you comment on the matter? > > There are situations where you need it, and there are situations > where it > hurts to have SETSID() called in the freshly created subprocess. > Probably > I encountered a case where it was needed, years ago, and put in the > call, > so that things behaved "correctly" w.r.t. Ctrl-C and logout. Maybe > this case > was that when the user presses Ctrl-C, the user expects to stop > clisp's > execution, but without the SETSID() the system sends a SIGINT > signal to the > subprocess, thus killing it. (Because clisp's signal handler for > Ctrl-C has > no effect on the subprocess.) Yes indeed - the whole thing is about signal handling. The problem was that even if setsid() is available (HAVE_SETSID) it has been emulated via setpgid() (since we have also HAVE_SETPGID). I changed it to use setsid() if available and only if not - "emulate" via setpgid(). Looks good on all platforms I tested on. Vladimir |