From: <don...@is...> - 2003-09-30 01:32:07
|
Anyone recognize the symptom below? Seems related to without-readline. I've now tried no --without, without-unicode, without-readline and both, and this happens in the two without readline. This is the cvs in which I'm building/testing write-byte-sequence but I don't see what that has to do with readline. ================ ./configure --without-readline nohang4-no-rl ... make ... [interrupt after creating lisp.run] [don@isis nohang4-no-rl]$ ./lisp.run i i i i i i i ooooo o ooooooo ooooo ooooo I I I I I I I 8 8 8 8 8 o 8 8 I \ `+' / I 8 8 8 8 8 8 \ `-+-' / 8 8 8 ooooo 8oooo `-__|__-' 8 8 8 8 8 | 8 o 8 8 o 8 8 ------+------ ooooo 8oooooo ooo8ooo ooooo 8 Copyright (c) Bruno Haible, Michael Stoll 1992, 1993 Copyright (c) Bruno Haible, Marcus Daniels 1994-1997 Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998 Copyright (c) Bruno Haible, Sam Steingold 1999-2003 WARNING: No initialization file specified. Please try: ./lisp.run -M lispinit.mem WARNING: No installation directory specified. Please try: ./lisp.run -B /usr/local/lib/clisp > *** - UNIX error 11 (EWOULDBLOCK): Operation would block 1. Break> *** - UNIX error 11 (EWOULDBLOCK): Operation would block 2. Break> *** - UNIX error 11 (EWOULDBLOCK): Operation would block ... |
From: Sam S. <sd...@gn...> - 2003-09-30 13:35:26
|
> * Don Cohen <qba...@vf...3-vap.pbz> [2003-09-29 18:26:12 -0700]: > > Anyone recognize the symptom below? > Seems related to without-readline. > I've now tried no --without, without-unicode, without-readline and > both, and this happens in the two without readline. > This is the cvs in which I'm building/testing write-byte-sequence > but I don't see what that has to do with readline. > > ================ > > ./configure --without-readline nohang4-no-rl > ... > make > ... > [interrupt after creating lisp.run] > > [don@isis nohang4-no-rl]$ ./lisp.run > i i i i i i i ooooo o ooooooo ooooo ooooo > I I I I I I I 8 8 8 8 8 o 8 8 > I \ `+' / I 8 8 8 8 8 8 > \ `-+-' / 8 8 8 ooooo 8oooo > `-__|__-' 8 8 8 8 8 > | 8 o 8 8 o 8 8 > ------+------ ooooo 8oooooo ooo8ooo ooooo 8 > > Copyright (c) Bruno Haible, Michael Stoll 1992, 1993 > Copyright (c) Bruno Haible, Marcus Daniels 1994-1997 > Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998 > Copyright (c) Bruno Haible, Sam Steingold 1999-2003 > > > WARNING: No initialization file specified. > Please try: ./lisp.run -M lispinit.mem > > WARNING: No installation directory specified. > Please try: ./lisp.run -B /usr/local/lib/clisp > > > > *** - UNIX error 11 (EWOULDBLOCK): Operation would block > 1. Break> > *** - UNIX error 11 (EWOULDBLOCK): Operation would block > 2. Break> > *** - UNIX error 11 (EWOULDBLOCK): Operation would block > ... never seen this. please build --with-debug and see what happens in GDB. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> If abortion is murder, then oral sex is cannibalism. |
From: <don...@is...> - 2003-09-30 16:13:54
|
Sam Steingold writes: > > * Don Cohen <qba...@vf...3-vap.pbz> [2003-09-29 18:26:12 -0700]: > > > > Anyone recognize the symptom below? > > Seems related to without-readline. > > I've now tried no --without, without-unicode, without-readline and > > both, and this happens in the two without readline. > > This is the cvs in which I'm building/testing write-byte-sequence > > but I don't see what that has to do with readline. > > > > ================ > > [don@isis nohang4-no-rl]$ ./lisp.run ... > > > > > *** - UNIX error 11 (EWOULDBLOCK): Operation would block > > 1. Break> > > *** - UNIX error 11 (EWOULDBLOCK): Operation would block > > 2. Break> > > *** - UNIX error 11 (EWOULDBLOCK): Operation would block > > ... > > never seen this. > please build --with-debug and see what happens in GDB. ./configure --without-readline --with-debug nohang4-no-rl-deb => no such problem. This is getting to be a habbit. I guess the next step is to try various points "between" with and without debug. Is the only difference in debug the gcc flags? |
From: Sam S. <sd...@gn...> - 2003-09-30 16:59:58
|
> * Don Cohen <qba...@vf...3-vap.pbz> [2003-09-30 09:07:50 -0700]: > > Sam Steingold writes: > > > * Don Cohen <qba...@vf...3-vap.pbz> [2003-09-29 18:26:12 -0700]: > > > > > > Anyone recognize the symptom below? > > > Seems related to without-readline. > > > I've now tried no --without, without-unicode, without-readline and > > > both, and this happens in the two without readline. > > > This is the cvs in which I'm building/testing write-byte-sequence > > > but I don't see what that has to do with readline. > > > > > > ================ > > > [don@isis nohang4-no-rl]$ ./lisp.run > ... > > > > > > > *** - UNIX error 11 (EWOULDBLOCK): Operation would block > > > 1. Break> > > > *** - UNIX error 11 (EWOULDBLOCK): Operation would block > > > 2. Break> > > > *** - UNIX error 11 (EWOULDBLOCK): Operation would block > > > ... > > > > never seen this. > > please build --with-debug and see what happens in GDB. > > ./configure --without-readline --with-debug nohang4-no-rl-deb > => no such problem. Add -DDEBUG_OS_ERROR to CFLAGS to learn which line generates this. > This is getting to be a habbit. :-) > I guess the next step is to try various points "between" with and > without debug. Is the only difference in debug the gcc flags? yes, but there are many ramifications. E.g., -DSAFETY=3 => no GENERATIONAL_GC. my bet is that this is what causes the problem, so please replace the -O -f* with -g -DDEBUG_OS_ERROR in CFLAGS. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> The early bird may get the worm, but the second mouse gets the cheese. |
From: <don...@is...> - 2003-09-30 17:28:34
|
> > ./configure --without-readline --with-debug nohang4-no-rl-deb > > => no such problem. > > Add -DDEBUG_OS_ERROR to CFLAGS to learn which line generates this. ... > E.g., -DSAFETY=3 => no GENERATIONAL_GC. > my bet is that this is what causes the problem, so please replace the > -O -f* with -g -DDEBUG_OS_ERROR in CFLAGS. Not sure what the -O -f* was about but I did try this: export CC="gcc -g -DDEBUG_OS_ERROR" ./configure --without-readline nohang4-no-rl-g-dbgos which gives gcc lines like: gcc -g -DDEBUG_OS_ERROR -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -fomit-frame-pointer -Wno-sign-compare -O2 -fexpensive-optimizations -DUNICODE -DDYNAMIC_FFI -DNO_READLINE -I. -x none spvw.o spvwtabf.o spvwtabs.o spvwtabo.o eval.o control.o encoding.o pathname.o stream.o socket.o io.o array.o hashtabl.o list.o package.o record.o sequence.o charstrg.o debug.o error.o misc.o time.o predtype.o symbol.o lisparit.o i18n.o foreign.o unixaux.o ari80386.o modules.o libcharset.a libavcall.a libcallback.a -lncurses -ldl -L/usr/local/lib -lsigsegv -lc -o lisp.run And this lisp.run also gives no error. So it must be either -g or -DDEBUG_OS_ERROR ? |
From: Sam S. <sd...@gn...> - 2003-09-30 17:38:48
|
> * Don Cohen <qba...@vf...3-vap.pbz> [2003-09-30 10:22:31 -0700]: > > > > ./configure --without-readline --with-debug nohang4-no-rl-deb > > > => no such problem. > > > > Add -DDEBUG_OS_ERROR to CFLAGS to learn which line generates this. > ... > > E.g., -DSAFETY=3 => no GENERATIONAL_GC. > > my bet is that this is what causes the problem, so please replace the > > -O -f* with -g -DDEBUG_OS_ERROR in CFLAGS. > > Not sure what the -O -f* was about but I did try this: -fomit-frame-pointer -O2 -fexpensive-optimizations may make your debugging harder, so I suggest editing your Makefile to remove them. > export CC="gcc -g -DDEBUG_OS_ERROR" > ./configure --without-readline nohang4-no-rl-g-dbgos > which gives gcc lines like: > gcc -g -DDEBUG_OS_ERROR -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -fomit-frame-pointer -Wno-sign-compare -O2 -fexpensive-optimizations -DUNICODE -DDYNAMIC_FFI -DNO_READLINE -I. -x none spvw.o spvwtabf.o spvwtabs.o spvwtabo.o eval.o control.o encoding.o pathname.o stream.o socket.o io.o array.o hashtabl.o list.o package.o record.o sequence.o charstrg.o debug.o error.o misc.o time.o predtype.o symbol.o lisparit.o i18n.o foreign.o unixaux.o ari80386.o modules.o libcharset.a libavcall.a libcallback.a -lncurses -ldl -L/usr/local/lib -lsigsegv -lc -o lisp.run > > And this lisp.run also gives no error. > So it must be either -g or -DDEBUG_OS_ERROR ? so, which one? -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> Those who value Life above Freedom are destined to lose both. |
From: <don...@is...> - 2003-09-30 18:04:21
|
The problem seems to have gone away. Perhaps due to cvs update or changes in my source or some combination. But I'll now try those techniques on the other case where --with-debug fixed the segfaults. |
From: <don...@is...> - 2003-09-30 20:20:00
|
Sam Steingold writes: > > > Add -DDEBUG_OS_ERROR to CFLAGS to learn which line generates this. > > ... > > > E.g., -DSAFETY=3 => no GENERATIONAL_GC. > > > my bet is that this is what causes the problem, so please replace the > > > -O -f* with -g -DDEBUG_OS_ERROR in CFLAGS. > > > > Not sure what the -O -f* was about but I did try this: > > -fomit-frame-pointer -O2 -fexpensive-optimizations may make your > debugging harder, so I suggest editing your Makefile to remove them. ==== Old ==== ./configure --without-readline --without-unicode CFLAGS = -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -fomit-frame-pointer -Wno-sign-compare -O2 -fexpensive-optimizations -DDYNAMIC_FFI -DNO_READLINE -I. result: builds lisp.run, gets up to ./lisp.run -B . -N locale -Efile UTF-8 -Eterminal UTF-8 -norc -m 750KW -x "(and (load \"init.lisp\") (sys::%saveinitmem) (ext::exit))" which gives make: *** [interpreted.mem] Segmentation fault ==== New ==== same configure CFLAGS = -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wno-sign-compare -g -DDEBUG_OS_ERROR -DDYNAMIC_FFI -DNO_READLINE -I. result: above lisp.run works! gets up to mv lispimag.mem halfcompiled.mem ./lisp.run -B . -N locale -Efile UTF-8 -Eterminal UTF-8 -norc -m 1000KW -M halfcompiled.mem -q -c init.lisp make: *** [init.fas] Segmentation fault (core dumped) make: *** Deleting file `init.fas' In fact at this point ./lisp.run -B . -N locale -Efile UTF-8 -Eterminal UTF-8 -norc -m 1000KW -M halfcompiled.mem works, though (compile-file "init.lisp") then segfaults. What does this tell us and what's the next step in finding the problem? Perhaps there are two problems? |
From: Sam S. <sd...@gn...> - 2003-09-30 20:34:41
|
> * Don Cohen <qba...@vf...3-vap.pbz> [2003-09-30 13:13:54 -0700]: > > Sam Steingold writes: > > > > > Add -DDEBUG_OS_ERROR to CFLAGS to learn which line generates this. > > > ... > > > > E.g., -DSAFETY=3 => no GENERATIONAL_GC. > > > > my bet is that this is what causes the problem, so please replace the > > > > -O -f* with -g -DDEBUG_OS_ERROR in CFLAGS. > > > > > > Not sure what the -O -f* was about but I did try this: > > > > -fomit-frame-pointer -O2 -fexpensive-optimizations may make your > > debugging harder, so I suggest editing your Makefile to remove them. > > ==== Old ==== > ./configure --without-readline --without-unicode > > CFLAGS = -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit > -Wreturn-type -fomit-frame-pointer -Wno-sign-compare -O2 > -fexpensive-optimizations -DDYNAMIC_FFI -DNO_READLINE -I. > > result: builds lisp.run, gets up to > ./lisp.run -B . -N locale -Efile UTF-8 -Eterminal UTF-8 -norc -m 750KW > -x "(and (load \"init.lisp\") (sys::%saveinitmem) (ext::exit))" > which gives > make: *** [interpreted.mem] Segmentation fault > > ==== New ==== > same configure > > CFLAGS = -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit > -Wreturn-type -Wno-sign-compare -g -DDEBUG_OS_ERROR -DDYNAMIC_FFI > -DNO_READLINE -I. > > result: above lisp.run works! gets up to > mv lispimag.mem halfcompiled.mem > ./lisp.run -B . -N locale -Efile UTF-8 -Eterminal UTF-8 -norc -m > 1000KW -M halfcompiled.mem -q -c init.lisp > make: *** [init.fas] Segmentation fault (core dumped) > make: *** Deleting file `init.fas' > > In fact at this point > ./lisp.run -B . -N locale -Efile UTF-8 -Eterminal UTF-8 -norc -m > 1000KW -M halfcompiled.mem > works, though (compile-file "init.lisp") then segfaults. > > What does this tell us and what's the next step in finding the problem? > Perhaps there are two problems? you have to run under gdb and see where you get the segfault. see src/.gdbinit (copied into your build directory) for various debugging goodies. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> Modern man is the missing link between apes and human beings. |
From: <don...@is...> - 2003-10-02 17:34:06
|
Sam Steingold writes (edited to keep only most relevant parts): > > > > > Add -DDEBUG_OS_ERROR to CFLAGS to learn which line generat= es this. > > > > > ... please replace the > > > > > -O -f* with -g -DDEBUG_OS_ERROR in CFLAGS. > > =3D=3D=3D=3D New =3D=3D=3D=3D > > ./configure --without-readline --without-unicode=20 > >=20 > > CFLAGS =3D -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit > > -Wreturn-type -Wno-sign-compare -g -DDEBUG_OS_ERROR -DDYNAMIC_FFI= > > -DNO_READLINE -I. > >=20 > > result: above lisp.run works! gets up to > > mv lispimag.mem halfcompiled.mem > > ./lisp.run -B . -N locale -Efile UTF-8 -Eterminal UTF-8 -norc -m > > 1000KW -M halfcompiled.mem -q -c init.lisp > > make: *** [init.fas] Segmentation fault (core dumped) > > make: *** Deleting file `init.fas' > >=20 > > In fact at this point > > ./lisp.run -B . -N locale -Efile UTF-8 -Eterminal UTF-8 -norc -m > > 1000KW -M halfcompiled.mem > > works, though (compile-file "init.lisp") then segfaults. > >=20 > > What does this tell us and what's the next step in finding the pro= blem? > > Perhaps there are two problems? =20 >=20 > you have to run under gdb and see where you get the segfault. > see src/.gdbinit (copied into your build directory) for various > debugging goodies. I notice that compile-file segfaults even with an empty source file. Below is gdb transcript of that. Let me know what this tells you and how to proceed. This is all using 2.31 source, BTW. [1]> (compile-file "foo.lisp") Program received signal SIGSEGV, Segmentation fault. 0x8067284 in interpret_bytecode_ (closure=3D0x2024a061, codeptr=3D0x202= 49b38,=20 byteptr_in=3D0x20249b4e ";\006\002~\006=3D\005;\004\002\016\006\020= \006;\006\002\016\a\020\a;\b\002\016\b\020\b;\n\003=CE\t\nc") at eval.d= :6326 6326=09eval.d: No such file or directory. [after the appropriate directory command: 6326=09 VALUES1(FRAME_(n)); ] (gdb) bt #0 0x8067284 in interpret_bytecode_ (closure=3D0x2024a061, codeptr=3D0= x20249b38,=20 byteptr_in=3D0x20249b4e ";\006\002~\006=3D\005;\004\002\016\006\020= \006;\006\002\016\a\020\a;\b\002\016\b\020\b;\n\003=CE\t\nc") at eval.d= :6326 #1 0x806283c in eval_closure (closure=3D0x2024a061) at eval.d:3768 #2 0x80604dc in eval1 (form=3D0x67ec7ab3) at eval.d:2946 #3 0x806017d in eval (form=3D0x67ec7ab3) at eval.d:2825 #4 0x80dd126 in C_read_eval_print () at debug.d:313 #5 0x806199d in eval_subr (fun=3D0x8145812) at eval.d:3461 #6 0x80604ac in eval1 (form=3D0x67f2574b) at eval.d:2939 #7 0x806017d in eval (form=3D0x67f2574b) at eval.d:2825 #8 0x8071fca in C_when () at control.d:1155 #9 0x80609aa in eval_fsubr (fun=3D0x201e94c9, args=3D0x67f256e3) at ev= al.d:3100 #10 0x8060537 in eval1 (form=3D0x67f25753) at eval.d:2955 #11 0x806017d in eval (form=3D0x67f25753) at eval.d:2825 #12 0x8073fc6 in C_catch () at control.d:1866 #13 0x80609aa in eval_fsubr (fun=3D0x201e95cd, args=3D0x67f256db) at ev= al.d:3100 #14 0x8060537 in eval1 (form=3D0x67f25773) at eval.d:2955 #15 0x806017d in eval (form=3D0x67f25773) at eval.d:2825 #16 0x805f9d6 in funcall_iclosure (closure=3D0x202bdeb5,=20 args_pointer=3D0x401d00a4, argcount=3D0) at eval.d:2593 #17 0x8066ec6 in funcall_closure (closure=3D0x202bdeb5, args_on_stack=3D= 0) at eval.d:5701 #18 0x806548c in funcall (fun=3D0x202bdeb5, args_on_stack=3D0) at eval.= d:4837 #19 0x8074464 in C_driver () at control.d:1938 #20 0x806199d in eval_subr (fun=3D0x8145692) at eval.d:3461 #21 0x80604ac in eval1 (form=3D0x67f25603) at eval.d:2939 #22 0x806017d in eval (form=3D0x67f25603) at eval.d:2825 #23 0x8070364 in C_progn () at control.d:331 #24 0x80609aa in eval_fsubr (fun=3D0x201e93b1, args=3D0x67f255f3) at ev= al.d:3100 #25 0x8060537 in eval1 (form=3D0x67f255eb) at eval.d:2955 #26 0x806017d in eval (form=3D0x67f255eb) at eval.d:2825 #27 0x805f9d6 in funcall_iclosure (closure=3D0x2028f1a5,=20 args_pointer=3D0x401d0048, argcount=3D0) at eval.d:2593 #28 0x8066ec6 in funcall_closure (closure=3D0x2028f1a5, args_on_stack=3D= 0) at eval.d:5701 #29 0x806548c in funcall (fun=3D0x2028f1a5, args_on_stack=3D0) at eval.= d:4837 #30 0x80dd385 in driver () at debug.d:379 #31 0x8057c0a in main (argc=3D14, argv=3D0xbffffbe4) at spvw.d:3005 #32 0x400a6f31 in __libc_start_main (main=3D0x8055e48 <main>, argc=3D14= ,=20 ubp_av=3D0xbffffbe4, init=3D0x8049a70 <_init>, fini=3D0x812cc24 <_f= ini>,=20 rtld_fini=3D0x4000e274 <_dl_fini>, stack_end=3D0xbffffbdc) at ../sysdeps/generic/libc-start.c:129 (gdb)=20 |
From: <don...@is...> - 2003-10-02 18:21:19
|
I offer this as a first draft of what I wish I had seen before I tried to modify the clisp c source. I hope others will answer the questions marked by *** and add more useful advice. I suggest putting the result in impnotes, ch. 32 ==== get the source If you hope to have your code incorporated into the distributed source then you have to generate diffs from a recent cvs version. The best way to get one is cvs. If you don't know what that is, try typing "cvs" into a command prompt. If it responds with help then you have it. Otherwise see http://www.cvshome.org/. Second best would be to download a nightly tarball from clisp.sourceforge.net. If you have cvs, then here's the recipe (copied from sourceforge.net) $ cvs -d:pserver:ano...@cv...:/cvsroot/clisp login responds with (Logging in to ano...@cv...) CVS password: You just respond to this prompt with the enter key. $ cd <dir> the directory <dir>/clisp is to be created by below $ cvs -z3 -d:pserver:ano...@cv...:/cvsroot/clisp co clisp Note - (2003/10) cvs commands often result in errors like this: cvs [diff aborted]: recv() from server cvs.sourceforge.net: EOF Just try again. And again ... Eventually you should end up with a source tree which you can then modify, build and test. ==== building from source This is described in the file INSTALL It is highly recommended that a directory be supplied to the configure command, i.e., don't build in the src directory. Sam also suggests naming build directories build-* which will cause them to be ignored in the cvs diff command below (creating a patch file). ==== resources for understanding and modifying the source The c source is in the src directory, in the form of .d files. As far as I can tell, this is not a standard format. The process for transforming .d to .c is ./comment5 stream.d | ./ansidecl | ./varbrace > stream.c These programs are in the utils directory. Unfortunately, the comments in the first two are still in German. The last one explains the var syntax you see in the .d files: # This preprocessor adds braces to source code, so that variable declarations # (introduced with the pseudo-keyword `var') can be used within blocks, like # in C++. # Example: # { # var decl1; # statement1; # var decl2; # statement2; # } # becomes # { # {var decl1; # statement1; # {var decl2; # statement2; # }} # } Above seems to be an example of comments recognized by comment5. [*** Can someone describe ansidecl and comment5?] Before reading much other source I suggest looking over clisp.h, which will help you make sense of all the other source. Before modifying code (at least if you plan to submit a patch), see src/CodingStyle Also, if you use emacs, emacs/d-mode.el ==== creating a patch file In order to generate a patch file that you can send to clisp-devel do something like this: $ cd <dir> where <dir> is the same directory you used in section "get the source" You may also have to redo the cvs login from that section. [*** When is that necessary? What are the side effects of login?] $ cvs -z3 -d:pserver:ano...@cv...:/cvsroot/clisp diff -uw clisp > /tmp/clisp-patch |
From: <don...@is...> - 2003-10-02 18:38:20
|
It seems that my mail is subtly altered on its way through sourceforge. I had section titles on lines starting with 4 equal signs but these seem to have been deleted. I now try sending without the equal signs, just guessing that this was somehow what caused those lines to be lost. (Anyone know about this phenomenon?) get the source If you hope to have your code incorporated into the distributed source then you have to generate diffs from a recent cvs version. The best way to get one is cvs. If you don't know what that is, try typing "cvs" into a command prompt. If it responds with help then you have it. Otherwise see http://www.cvshome.org/. Second best would be to download a nightly tarball from clisp.sourceforge.net. If you have cvs, then here's the recipe (copied from sourceforge.net) $ cvs -d:pserver:ano...@cv...:/cvsroot/clisp login responds with (Logging in to ano...@cv...) CVS password: You just respond to this prompt with the enter key. $ cd <dir> the directory <dir>/clisp is to be created by below $ cvs -z3 -d:pserver:ano...@cv...:/cvsroot/clisp co clisp Note - (2003/10) cvs commands often result in errors like this: cvs [diff aborted]: recv() from server cvs.sourceforge.net: EOF Just try again. And again ... Eventually you should end up with a source tree which you can then modify, build and test. building from source This is described in the file INSTALL It is highly recommended that a directory be supplied to the configure command, i.e., don't build in the src directory. Sam also suggests naming build directories build-* which will cause them to be ignored in the cvs diff command below (creating a patch file). resources for understanding and modifying the source The c source is in the src directory, in the form of .d files. As far as I can tell, this is not a standard format. The process for transforming .d to .c is ./comment5 stream.d | ./ansidecl | ./varbrace > stream.c These programs are in the utils directory. Unfortunately, the comments in the first two are still in German. The last one explains the var syntax you see in the .d files: # This preprocessor adds braces to source code, so that variable declarations # (introduced with the pseudo-keyword `var') can be used within blocks, like # in C++. # Example: # { # var decl1; # statement1; # var decl2; # statement2; # } # becomes # { # {var decl1; # statement1; # {var decl2; # statement2; # }} # } Above seems to be an example of comments recognized by comment5. [*** Can someone describe ansidecl and comment5?] Before reading much other source I suggest looking over clisp.h, which will help you make sense of all the other source. Before modifying code (at least if you plan to submit a patch), see src/CodingStyle Also, if you use emacs, emacs/d-mode.el creating a patch file In order to generate a patch file that you can send to clisp-devel do something like this: $ cd <dir> where <dir> is the same directory you used in section "get the source" You may also have to redo the cvs login from that section. [*** When is that necessary? What are the side effects of login?] $ cvs -z3 -d:pserver:ano...@cv...:/cvsroot/clisp diff -uw clisp > /tmp/clisp-patch |
From: Sam S. <sd...@gn...> - 2003-10-02 19:08:38
|
> * Don Cohen <qba...@vf...3-vap.pbz> [2003-10-02 11:31:49 -0700]: > > It seems that my mail is subtly altered on its way through > sourceforge. I had section titles on lines starting with 4 equal > signs but these seem to have been deleted. this is your mail reader messing up (quoted readable?) I saw === just fine. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> The software said it requires Windows 3.1 or better, so I installed Linux. |
From: Sam S. <sd...@gn...> - 2003-10-02 19:17:20
|
> * Don Cohen <qba...@vf...3-vap.pbz> [2003-10-02 10:27:34 -0700= ]: > > Sam Steingold writes (edited to keep only most relevant parts): > > > > > > Add -DDEBUG_OS_ERROR to CFLAGS to learn which line generates= this. > > > > > > ... please replace the > > > > > > -O -f* with -g -DDEBUG_OS_ERROR in CFLAGS. > > > =3D=3D=3D=3D New =3D=3D=3D=3D > > > ./configure --without-readline --without-unicode=20 > > >=20 > > > CFLAGS =3D -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit > > > -Wreturn-type -Wno-sign-compare -g -DDEBUG_OS_ERROR -DDYNAMIC_FFI > > > -DNO_READLINE -I. > > >=20 > > > result: above lisp.run works! gets up to > > > mv lispimag.mem halfcompiled.mem > > > ./lisp.run -B . -N locale -Efile UTF-8 -Eterminal UTF-8 -norc -m > > > 1000KW -M halfcompiled.mem -q -c init.lisp > > > make: *** [init.fas] Segmentation fault (core dumped) > > > make: *** Deleting file `init.fas' > > >=20 > > > In fact at this point > > > ./lisp.run -B . -N locale -Efile UTF-8 -Eterminal UTF-8 -norc -m > > > 1000KW -M halfcompiled.mem > > > works, though (compile-file "init.lisp") then segfaults. > > >=20 > > > What does this tell us and what's the next step in finding the probl= em? > > > Perhaps there are two problems?=20=20 > >=20 > > you have to run under gdb and see where you get the segfault. > > see src/.gdbinit (copied into your build directory) for various > > debugging goodies. >=20 > I notice that compile-file segfaults even with an empty source file. > Below is gdb transcript of that. Let me know what this tells you > and how to proceed. This is all using 2.31 source, BTW. >=20 > [1]> (compile-file "foo.lisp") >=20 > Program received signal SIGSEGV, Segmentation fault. > 0x8067284 in interpret_bytecode_ (closure=3D0x2024a061, codeptr=3D0x20249= b38,=20 > byteptr_in=3D0x20249b4e ";\006\002~\006=3D\005;\004\002\016\006\020\0= 06;\006\002\016\a\020\a;\b\002\016\b\020\b;\n\003=C3=8E\t\nc") at eval.d:63= 26 > 6326 eval.d: No such file or directory. >=20 > [after the appropriate directory command: > 6326 VALUES1(FRAME_(n)); > ] >=20 > (gdb) bt > #0 0x8067284 in interpret_bytecode_ (closure=3D0x2024a061, codeptr=3D0x2= 0249b38,=20 > byteptr_in=3D0x20249b4e ";\006\002~\006=3D\005;\004\002\016\006\020\0= 06;\006\002\016\a\020\a;\b\002\016\b\020\b;\n\003=C3=8E\t\nc") at eval.d:63= 26 > #1 0x806283c in eval_closure (closure=3D0x2024a061) at eval.d:3768 > #2 0x80604dc in eval1 (form=3D0x67ec7ab3) at eval.d:2946 > #3 0x806017d in eval (form=3D0x67ec7ab3) at eval.d:2825 > #4 0x80dd126 in C_read_eval_print () at debug.d:313 > #5 0x806199d in eval_subr (fun=3D0x8145812) at eval.d:3461 > #6 0x80604ac in eval1 (form=3D0x67f2574b) at eval.d:2939 > #7 0x806017d in eval (form=3D0x67f2574b) at eval.d:2825 > #8 0x8071fca in C_when () at control.d:1155 > #9 0x80609aa in eval_fsubr (fun=3D0x201e94c9, args=3D0x67f256e3) at eval= .d:3100 > #10 0x8060537 in eval1 (form=3D0x67f25753) at eval.d:2955 > #11 0x806017d in eval (form=3D0x67f25753) at eval.d:2825 > #12 0x8073fc6 in C_catch () at control.d:1866 > #13 0x80609aa in eval_fsubr (fun=3D0x201e95cd, args=3D0x67f256db) at eval= .d:3100 > #14 0x8060537 in eval1 (form=3D0x67f25773) at eval.d:2955 > #15 0x806017d in eval (form=3D0x67f25773) at eval.d:2825 > #16 0x805f9d6 in funcall_iclosure (closure=3D0x202bdeb5,=20 > args_pointer=3D0x401d00a4, argcount=3D0) at eval.d:2593 > #17 0x8066ec6 in funcall_closure (closure=3D0x202bdeb5, args_on_stack=3D0) > at eval.d:5701 > #18 0x806548c in funcall (fun=3D0x202bdeb5, args_on_stack=3D0) at eval.d:= 4837 > #19 0x8074464 in C_driver () at control.d:1938 > #20 0x806199d in eval_subr (fun=3D0x8145692) at eval.d:3461 > #21 0x80604ac in eval1 (form=3D0x67f25603) at eval.d:2939 > #22 0x806017d in eval (form=3D0x67f25603) at eval.d:2825 > #23 0x8070364 in C_progn () at control.d:331 > #24 0x80609aa in eval_fsubr (fun=3D0x201e93b1, args=3D0x67f255f3) at eval= .d:3100 > #25 0x8060537 in eval1 (form=3D0x67f255eb) at eval.d:2955 > #26 0x806017d in eval (form=3D0x67f255eb) at eval.d:2825 > #27 0x805f9d6 in funcall_iclosure (closure=3D0x2028f1a5,=20 > args_pointer=3D0x401d0048, argcount=3D0) at eval.d:2593 > #28 0x8066ec6 in funcall_closure (closure=3D0x2028f1a5, args_on_stack=3D0) > at eval.d:5701 > #29 0x806548c in funcall (fun=3D0x2028f1a5, args_on_stack=3D0) at eval.d:= 4837 > #30 0x80dd385 in driver () at debug.d:379 > #31 0x8057c0a in main (argc=3D14, argv=3D0xbffffbe4) at spvw.d:3005 > #32 0x400a6f31 in __libc_start_main (main=3D0x8055e48 <main>, argc=3D14,= =20 > ubp_av=3D0xbffffbe4, init=3D0x8049a70 <_init>, fini=3D0x812cc24 <_fin= i>,=20 > rtld_fini=3D0x4000e274 <_dl_fini>, stack_end=3D0xbffffbdc) > at ../sysdeps/generic/libc-start.c:129 > (gdb)=20 zbacktrace will give you the CLISP backtrace. what are k1, k2, n? can you reproduce this when you build with g++ and DEBUG_GCSAFETY? this might catch the original problem early on. (I remember you had problems with g++, did you manage to build with g++?) --=20 Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> Someone has changed your life. Save? (y/n) |
From: <don...@is...> - 2003-10-02 19:46:26
|
Sam Steingold writes: > zbacktrace will give you the CLISP backtrace. Does that help me find the segfault? > what are k1, k2, n? Below. What do they mean? Again, what's the relation to segfault? (gdb) zbacktrace Undefined command: "zbacktrace". Try "help". (gdb) p back_trace_out(0,0) [0/0xBFFFAC4C]> #<COMPILED-CLOSURE COMMON-LISP::COMPILE-FILE> delta: STACK=11; SP=24 [1/0xBFFFADD8]> #<SYSTEM-FUNCTION SYSTEM::READ-EVAL-PRINT> delta: STACK=5; SP=24 [2/0xBFFFAF60]> #<SPECIAL-OPERATOR COMMON-LISP::WHEN> delta: STACK=7; SP=33 [3/0xBFFFB178]> #<SPECIAL-OPERATOR COMMON-LISP::CATCH> delta: STACK=18; SP=36 [4/0xBFFFB3B8]> #<CLOSURE :LAMBDA> 0 args delta: STACK=2; SP=22 [5/0xBFFFB520]> #<SYSTEM-FUNCTION SYSTEM::DRIVER> delta: STACK=4; SP=24 [6/0xBFFFB6A8]> #<SPECIAL-OPERATOR COMMON-LISP::PROGN> delta: STACK=17; SP=36 [7/0xBFFFB8E8]> #<CLOSURE SYSTEM::MAIN-LOOP> 0 args delta: STACK=0; SP=20 [8/0xBFFFBA30]> #<SYSTEM-FUNCTION SYSTEM::DRIVER> $1 = 9 (gdb) p k1 $2 = 2 (gdb) p k2 $3 = 1 (gdb) p n $4 = 47 (gdb) > can you reproduce this when you build with g++ and DEBUG_GCSAFETY? > this might catch the original problem early on. First I've heard of it. Is there some configure option I should try or you mean export CC="gcc -DDEBUG_GCSAFETY" ? And what does this do? > (I remember you had problems with g++, did you manage to build with g++?) Not even close. I thought you had the same problems. |
From: Sam S. <sd...@gn...> - 2003-10-02 20:18:36
|
> * Don Cohen <qba...@vf...3-vap.pbz> [2003-10-02 12:24:32 -0700]: > > Sam Steingold writes: > > zbacktrace will give you the CLISP backtrace. > Does that help me find the segfault? maybe. > > what are k1, k2, n? > Below. What do they mean? see <http://clisp.cons.org/impnotes/intr-set.html> instruction (LOADI) what is the value of FRAME? can you print (with zout) things like FRAME[-1] (== FRAME_(0))? > Again, what's the relation to segfault? well... > (gdb) zbacktrace > Undefined command: "zbacktrace". Try "help". > (gdb) p back_trace_out(0,0) > [0/0xBFFFAC4C]> #<COMPILED-CLOSURE COMMON-LISP::COMPILE-FILE> delta: STACK=11; SP=24 > [1/0xBFFFADD8]> #<SYSTEM-FUNCTION SYSTEM::READ-EVAL-PRINT> delta: STACK=5; SP=24 > [2/0xBFFFAF60]> #<SPECIAL-OPERATOR COMMON-LISP::WHEN> delta: STACK=7; SP=33 > [3/0xBFFFB178]> #<SPECIAL-OPERATOR COMMON-LISP::CATCH> delta: STACK=18; SP=36 > [4/0xBFFFB3B8]> #<CLOSURE :LAMBDA> 0 args delta: STACK=2; SP=22 > [5/0xBFFFB520]> #<SYSTEM-FUNCTION SYSTEM::DRIVER> delta: STACK=4; SP=24 > [6/0xBFFFB6A8]> #<SPECIAL-OPERATOR COMMON-LISP::PROGN> delta: STACK=17; SP=36 > [7/0xBFFFB8E8]> #<CLOSURE SYSTEM::MAIN-LOOP> 0 args delta: STACK=0; SP=20 > [8/0xBFFFBA30]> #<SYSTEM-FUNCTION SYSTEM::DRIVER> > $1 = 9 > (gdb) p k1 > $2 = 2 > (gdb) p k2 > $3 = 1 > (gdb) p n > $4 = 47 > (gdb) these do not look too terrible... > > can you reproduce this when you build with g++ and DEBUG_GCSAFETY? > > this might catch the original problem early on. > First I've heard of it. Is there some configure option I should try > or you mean export CC="gcc -DDEBUG_GCSAFETY" ? CC=g++ ./configure --with-debug enables DEBUG_GCSAFETY > And what does this do? run-time GC-safety checks. it crashes immediately when you try to access an object invalidated by the GC. > > (I remember you had problems with g++, did you manage to build with g++?) > Not even close. I thought you had the same problems. on cygwin, yes. I can build with g++ on linux (rh9) -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> There is an exception to every rule, including this one. |
From: <don...@is...> - 2003-10-02 21:14:42
|
Sam Steingold writes: > what is the value of FRAME? (gdb) print FRAME $1 = (gcv_object_t *) 0x2d6 > can you print (with zout) things like FRAME[-1] (== FRAME_(0))? (gdb) zout FRAME Program received signal SIGSEGV, Segmentation fault. 0x80b01bc in pr_subr (stream_=0x401d02f4, obj=0x2d6) at io.d:9118 9118 pr_other_obj(stream_,TheSubr(obj)->name, The program being debugged was signaled while in a function called from GDB. GDB remains in the frame where the signal was received. To change this behavior use "set unwindonsignal on" Evaluation of the expression containing the function (object_out) will be abandoned. I guess that's the same problem we want to debug. Now what? > CC=g++ ./configure --with-debug > enables DEBUG_GCSAFETY But that also removes the bug. So I guess you want me to add DEBUG_GCSAFETY to the c flags. ... lispbibl.d:2304: #error "DEBUG_GCSAFETY works only with a C++ compiler! Reconfigure with CC=g++." make: *** [spvw.o] Error 1 Oh. Well, that won't work - see below. > on cygwin, yes. > I can build with g++ on linux (rh9) Ended with g++ -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wno-sign-compare -g -DDEBUG_OS_ERROR -DDEBUG_SPVW -DSAFETY=3 -DDEBUG_GCSAFETY -DNO_TYPECODES -DUNICODE -DDYNAMIC_FFI -I. -c encoding.c In file included from encoding.d:7: lispbibl.d:7384: warning: volatile register variables don't work as you might wish encoding.d: In function `Values C_charset_range()': encoding.d:1957: Internal compiler error in `instantiate_virtual_regs_1', at function.c:3863 Please submit a full bug report. See <URL:http://www.gnu.org/software/gcc/faq.html#bugreport> for instructions. make: *** [encoding.o] Error 1 Of course, this is gcc 2.95.2.1 ... |