CLISP - an ANSI Common Lisp

Sam Steingold writes:

 > are you saying that the outcome depends on the time format?
It's interesting that Vladimir sent a cvs command that said
specifically 00:01.  Perhaps I was mistaken in imagining that this
was a time of day (one minute past midnight).

I have 6 examples that use 00:01 and none of them end in i18n errors.

There are 5 that use colons OTHER than 00:01, and they all end in
i18n errors.

There are 14 with no colons and none of them end in i18n errors.

 > it is certainly worth investigating.
 > specifically, check out two trees with the same date (with and without the 
 > colon), configure and observe the error.
It's interesting that right after checkout there are no differences.
After configure diff -ur generates ~450 lines
I've been wondering what causes this (and many variants of it):
-cl_cv_address_malloc=${cl_cv_address_malloc=0x09000000} 
+cl_cv_address_malloc=${cl_cv_address_malloc=0x08000000} 

Other than that I see temporary file names and the names of the
different directories.

I now notice that the cases where I've used hh:mm other than 0001 
are also exactly the cases where the directory name contains a colon,
i.e., 2009-08-07-02:00 - perhaps this is the problem...

When I compare the build transcripts of two such, ignoring the
directory names and the 80000000 vs 90000000, the first interesting
difference appears 39% through the transcript:

 make[1]: Leaving directory `/root/clisp-versions/2009-08-06-0001/clisp/build-mt/gllib' 
 echo '#include "config.h"' > tmp.c 
 cat '../src/intparam.c' >> tmp.c  
 gcc tmp.c -o intparam 
 ./intparam intparam.h 
 rm -f intparam tmp.c 

at this point in the version with : I see

 echo '#include "config.h"' > tmp.c 
 cat '../src/floatparam.c' >> tmp.c 
 gcc tmp.c -o floatparam 
 ./floatparam floatparam.h 
 rm -f floatparam tmp.c 

At that point they both continue with

 gcc -I/root/clisp-versions/2009-08-06-0001/clisp/build-mt/gllib -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -pthread -DUNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_FFI -I.   ../utils/comment5.c -o comment5 
 gcc -I/root/clisp-versions/2009-08-06-0001/clisp/build-mt/gllib -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -pthread -DUNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_FFI -I.   ../utils/gctrigger.c -o gctrigger 

and the next difference is at the end where the one with colon reports

 Makefile:23: *** target pattern contains no `%'.  Stop. 
 make[1]: Leaving directory `/root/clisp-versions/2009-08-06-0001/clisp/build-mt/i18n' 
 make: *** [i18n] Error 2 

and the other continues on

 > then compare the directory trees to figure out how they differ
 > (either use emacs or a shell tool, google for compare directories).
diff -ur generates 280K ...
So far it's looking pretty painful to search through that.
If the info above doesn't help, let me know what you think is worth
looking for in this diff or otherwise.

On 10/5/09, Don Cohen <don-sourceforge-xxz@...> wrote:
> Vladimir Tzankov writes:
>  > I guess the problem is the same or related to this one:
>  > http://thread.gmane.org/gmane.lisp.clisp.devel/20732/
>  >
>  > Currently I cannot reproduce it but I remember that when inspecting
>  > the C stack there was extra value pushed when vectorof was called.
>
> I'm willing to do experiments but you'll have to describe in some
> detail what you want me to try.
Thanks.

Let's see whether it is the same problem as reported above. In order
to do so you should change the Makefile to keep base/ folder in case
of errors - remove "$(RMRF) base" from base target. After you make
(and it fails) there should be base/ folder.
Now you can run the whole thing under gdb (with all parameters as from
make) and see where the segfault happens - please paste stack trace
here.

Something like (in your build directory):
vtz@...$ gdb base/lisp.run
(gdb) set args -B . -M base/lispinit.mem -norc -q -i i18n/i18n -i
syscalls/posix -i regexp/regexp -i readline/readline
(gdb) delete
(gdb) handle SIGSEGV nostop noprint
(gdb) break spvw_sigsegv.d:65
(gdb) run

It should stop at spvw_sigsegv.d:65 - hope the stack is not corrupted.

You may try the same thing but removing some of the modules from
command line (-i options).

Vladimir

Vladimir Tzankov writes:

 > Let's see whether it is the same problem as reported above. In order
 > to do so you should change the Makefile to keep base/ folder in case
 > of errors - remove "$(RMRF) base" from base target. After you make
 > (and it fails) there should be base/ folder.

 base : modular boot $(BASE_MODULES) 
        # *** $(RMRF) base 
        MAKE=$(MAKE) CLISP="/root/clisp/build-mt-yes/clisp -K boot  -E UTF-8 -E pathname 1:1 -Emisc 1:1 -norc" with_dynamic_modules=no ./clisp-link add boot base $(BASE_MODULES) || exit 1 
 # *** ($(RMRF) base ; exit 1) 
 
then make, now
 $ ls base 
 calls.o      libgnu_rx.a      lisp.a        modules.h   regexi.o 
 gettext.o    libgnu_sc.a      lispinit.mem  modules.o 
 libgnu_cl.a  libnoreadline.a  lisp.run      readline.o 

 > Now you can run the whole thing under gdb (with all parameters as from
 > make) and see where the segfault happens - please paste stack trace
 > here.
 > 
 > Something like (in your build directory):
 > vtz@...$ gdb base/lisp.run
 > (gdb) set args -B . -M base/lispinit.mem -norc -q -i i18n/i18n -i
 > syscalls/posix -i regexp/regexp -i readline/readline
 > (gdb) delete
 > (gdb) handle SIGSEGV nostop noprint
 > (gdb) break spvw_sigsegv.d:65
 > (gdb) run


 $ gdb base/lisp.run  
 GNU gdb Red Hat Linux (6.3.0.0-1.84rh) 
 Copyright 2004 Free Software Foundation, Inc. 
 GDB is free software, covered by the GNU General Public License, and you are 
 welcome to change it and/or distribute copies of it under certain conditions. 
 Type "show copying" to see the conditions. 
 There is absolutely no warranty for GDB.  Type "show warranty" for details. 
 This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". 

 Breakpoint 1 at 0x80a0664: file ../src/eval.d, line 4858. 
 Breakpoint 2 at 0x809a330: file ../src/eval.d, line 4038. 
 Breakpoint 3 at 0x8096f7c: file ../src/eval.d, line 2949. 
 Breakpoint 4 at 0x809a530: file ../src/eval.d, line 5771. 

I guess we're loading a gdb init file...
 ...
 15  breakpoint     keep y   0x0812bd96 in errno_out_low 
                                       at ../src/errunix.d:723 
 Breakpoint 16 at 0x8081192: file ../src/spvw_sigsegv.d, line 64. 

That looks pretty similar to your breakpoint, btw.

 .gdbinit:197: Error in sourced command file: 
 No symbol "byteptr" in current context. 
 (gdb) set args -B . -M base/lispinit.mem -norc -q -i i18n/i18n -i syscalls/posi x -i regexp/regexp -i readline/readline 

I left out the -x saveinitmem

 (gdb) delete 
 Delete all breakpoints? (y or n) y 
 Please answer y or n. 
 Delete all breakpoints? (y or n) y 
 (gdb) handle SIGSEGV nostop noprint 
 Signal        Stop      Print   Pass to program Description 
 SIGSEGV       No        No      Yes             Segmentation fault 
 (gdb) break spvw_sigsegv.d:65 
 Breakpoint 17 at 0x808119f: file ../src/spvw_sigsegv.d, line 65. 
 (gdb) run 
 Starting program: /root/clisp/build-mt-yes/base/lisp.run -B . -M base/lispinit. mem -norc -q -i i18n/i18n -i syscalls/posix -i regexp/regexp -i readline/readline 
 Reading symbols from shared object read from target memory...done. 
 Loaded system supplied DSO at 0x6dc000 
 [Thread debugging using libthread_db enabled] 
 [New Thread 1120480 (LWP 5728)] 
 
 *** - handle_fault error2 ! address = 0x1 not in
 [0x208cd004,0x20a29cc4) ! 
 [Switching to Thread 1120480 (LWP 5728)] 
 
 Breakpoint 17, sigsegv_handler_failed (address=0x1) 
    at ../src/spvw_sigsegv.d:65 
 65        fprintf(stderr,GETTEXTL("SIGSEGV cannot be cured. Fault address = 0x%lx."), 
 (gdb) bt 

I hope I guessed right that bt is what I was supposed to do here.

 #0  sigsegv_handler_failed (address=0x1) at ../src/spvw_sigsegv.d:65 
 #1  0x080812c4 in sigsegv_handler (fault_address=0x1, serious=1) 
     at ../src/spvw_sigsegv.d:80 
 #2  0x0816f399 in sigsegv_handler (sig=11, sc= 
       {gs = 51, __gsh = 0, fs = 0, __fsh = 0, es = 123, __esh = 49216, ds = 123, __dsh = 0, edi = 1120484, esi = 136579072, ebp = 3220618360, esp = 3220618324 , ebx = 136451968, edx = 546933198, ecx = 1121592, eax = 1, trapno = 14, err =  6, eip = 134689291, cs = 115, __csh = 0, eflags = 66071, esp_at_signal = 322061 8324, ss = 123, __ssh = 0, fpstate = 0xbff6fa5c, oldmask = 134244399, cr2 = 1}) at handler-unix.c:219 
 #3  <signal handler called> 
 #4  0x0807320b in module__syscalls__init_function_1 (module=0x8221ca0) 
     at /root/clisp/modules/syscalls/calls.c:6359 
 #5  0x08088cf7 in init_module_2 (module=0x8221ca0) at ../src/spvw.d:2066 
 #6  0x08089020 in init_other_modules_2 () at ../src/spvw.d:2070 
 #7  0x0808bee1 in main (argc=15, argv=0xbff6fe04) at ../src/spvw.d:3926 
 (gdb)

On 10/6/09, Don Cohen <don-sourceforge-xxz@...> wrote:
> Vladimir Tzankov writes:
>
>  > Let's see whether it is the same problem as reported above. In order
>  > to do so you should change the Makefile to keep base/ folder in case
>  > of errors - remove "$(RMRF) base" from base target. After you make
>  > (and it fails) there should be base/ folder.
>  (gdb) bt
>
> I hope I guessed right that bt is what I was supposed to do here.
>
>  #0  sigsegv_handler_failed (address=0x1) at ../src/spvw_sigsegv.d:65
>  #1  0x080812c4 in sigsegv_handler (fault_address=0x1, serious=1)
>      at ../src/spvw_sigsegv.d:80
>  #2  0x0816f399 in sigsegv_handler (sig=11, sc=
>        {gs = 51, __gsh = 0, fs = 0, __fsh = 0, es = 123, __esh = 49216, ds =
> 123, __dsh = 0, edi = 1120484, esi = 136579072, ebp = 3220618360, esp =
> 3220618324 , ebx = 136451968, edx = 546933198, ecx = 1121592, eax = 1,
> trapno = 14, err =  6, eip = 134689291, cs = 115, __csh = 0, eflags = 66071,
> esp_at_signal = 322061 8324, ss = 123, __ssh = 0, fpstate = 0xbff6fa5c,
> oldmask = 134244399, cr2 = 1}) at handler-unix.c:219
>  #3  <signal handler called>
>  #4  0x0807320b in module__syscalls__init_function_1 (module=0x8221ca0)
>      at /root/clisp/modules/syscalls/calls.c:6359
>  #5  0x08088cf7 in init_module_2 (module=0x8221ca0) at ../src/spvw.d:2066
>  #6  0x08089020 in init_other_modules_2 () at ../src/spvw.d:2070
>  #7  0x0808bee1 in main (argc=15, argv=0xbff6fe04) at ../src/spvw.d:3926
>  (gdb)

Looks like the same problem. vectorof() is not in the back trace but
it is one of the two functions called from
module__syscalls__init_function_1().

Can you try following:
1. leave just syscalls module on the command line
2. set a breakpoint at spvw.d:2066
3. after the above breakpoint is hit - set another one in array.d:170
(vectorof) and continue

you should hit at least once the breakpoint in vectorof. what is the len?
also what is in the C stack (x /16 $esp).

When I experienced this problem len parameter was not at "correct"
offset on the C stack (however I do not have an idea why).

Vladimir

Vladimir Tzankov writes:

 > Can you try following:
 > 1. leave just syscalls module on the command line
 > 2. set a breakpoint at spvw.d:2066
 > 3. after the above breakpoint is hit - set another one in array.d:170
 > (vectorof) and continue
See whether this is what you meant:

 $ gdb base/lisp.run  
 GNU gdb Red Hat Linux (6.3.0.0-1.84rh) 
  ...
 (gdb) set args -B . -M base/lispinit.mem -norc -q -i syscalls/posix 
 (gdb) delete 
 Delete all breakpoints? (y or n) y 
 (gdb) handle SIGSEGV nostop noprint 
 Signal        Stop      Print   Pass to program Description 
 SIGSEGV       No        No      Yes             Segmentation fault 
 (gdb) break spvw.d:2066 
 Breakpoint 17 at 0x8088ceb: file ../src/spvw.d, line 2066. 
 (gdb) run 
 Starting program: /root/clisp/build-mt-yes/base/lisp.run -B . -M base/lispinit.mem -norc -q -i syscalls/posix 
 Reading symbols from shared object read from target memory...done. 
 Loaded system supplied DSO at 0x6dc000 
 [Thread debugging using libthread_db enabled] 
 [New Thread 1124352 (LWP 7602)] 
 [Switching to Thread 1124352 (LWP 7602)] 

 Breakpoint 17, init_module_2 (module=0x8221c70) at ../src/spvw.d:2066 
 2066      (*module->initfunction1)(module); 
 (gdb) break array.d:170 
 Breakpoint 18 at 0x80f5a90: file ../src/array.d, line 170. 
 (gdb) continue 
 Continuing. 

 Breakpoint 17, init_module_2 (module=0x8221ca0) at ../src/spvw.d:2066 
 2066      (*module->initfunction1)(module); 
 (gdb) continue 
 Continuing. 

 *** - handle_fault error2 ! address = 0x1 not in [0x205ef004,0x2074bcc4) ! 
 SIGSEGV cannot be cured. Fault address = 0x1. 
 GC count: 0 
 Space collected by GC: 0 0 
 Run time: 0 28001 
 Real time: 80 110886 
 GC time: 0 0 
 Permanently allocated: 110616 bytes. 
 Currently in use: 2073432 bytes. 
 Free space: 353648 bytes. 
 Couldn't get registers: No such process. 
 (gdb)  

I guess either I failed to understand you or you didn't correctly
predict what would happen.  I await further instruction.

 > you should hit at least once the breakpoint in vectorof. what is the len?

Tell me what to type in order to find out.

 > also what is in the C stack (x /16 $esp).
I gather the stuff in parens is the command to enter - that's what I
need. 

 > When I experienced this problem len parameter was not at "correct"
 > offset on the C stack (however I do not have an idea why).
 > 
 > Vladimir

On 10/6/09, Don Cohen <don-sourceforge-xxz@...> wrote:
>  Breakpoint 17, init_module_2 (module=0x8221c70) at ../src/spvw.d:2066
>  2066      (*module->initfunction1)(module);
>  (gdb) break array.d:170
>  Breakpoint 18 at 0x80f5a90: file ../src/array.d, line 170.
>  (gdb) continue
>  Continuing.
>
>  Breakpoint 17, init_module_2 (module=0x8221ca0) at ../src/spvw.d:2066
>  2066      (*module->initfunction1)(module);
>  (gdb) continue
>  Continuing.
>
>  *** - handle_fault error2 ! address = 0x1 not in [0x205ef004,0x2074bcc4) !
>  SIGSEGV cannot be cured. Fault address = 0x1.
> ...
> I guess either I failed to understand you or you didn't correctly
> predict what would happen.  I await further instruction.

Yep, you did not reach at all vectorof().
On the second break at spvw.d:2066 do:
1. p /x *module   - to see the module data
2. use "step" until you get segfault. count the times "step" was
issued since gdb will not be able to find the source line number.

Vladimir Tzankov writes:
 > On the second break at spvw.d:2066 do:
 > 1. p /x *module   - to see the module data
 > 2. use "step" until you get segfault. count the times "step" was
 > issued since gdb will not be able to find the source line number.

Breakpoint 17, init_module_2 (module=0x8221ca0) at ../src/spvw.d:2066 
2066      (*module->initfunction1)(module); 
(gdb) p /x *module 
$1 = {name = 0x817112d, stab = 0x8222974, stab_size = 0x8221e40,  
  otab = 0x8240800, otab_size = 0x8221e44, initialized = 0x1,  
  stab_initdata = 0x8221e60, otab_initdata = 0x8222180,  
  initfunction1 = 0x80731d8, initfunction2 = 0x80731cc,  
  finifunction = 0x8073408, next = 0x8221cd0} 
(gdb) step 
module__syscalls__init_function_1 (module=0x8221ca0) 
    at /root/clisp/modules/syscalls/calls.c:6359 
Line number 6359 out of range; /root/clisp/modules/syscalls/calls.c has 5492 lines. 
(gdb) help step 
Step program until it reaches a different source line. 
Argument N means do this N times (or till program stops for another reason). 
(gdb) step 
sigsegv_handler (sig=11, sc= 
      {gs = 51, __gsh = 0, fs = 0, __fsh = 0, es = 123, __esh = 49216, ds = 123, __dsh = 0, edi = 1120484, esi = 136579072, ebp = 3220833528, esp = 3220833492, ebx = 136451968, edx = 545438158, ecx = 1121592, eax = 1, trapno = 14, err = 6, eip = 134689291, cs = 115, __csh = 0, eflags = 66071, esp_at_signal = 3220833492, ss = 123, __ssh = 0, fpstate = 0xbffa42dc, oldmask = 134244399, cr2 = 1}) at handler-unix.c:125 
125     { 
(gdb)

On 10/6/09, Don Cohen <don-sourceforge-xxz@...> wrote:
> Vladimir Tzankov writes:
>  > On the second break at spvw.d:2066 do:
>  > 1. p /x *module   - to see the module data
>  > 2. use "step" until you get segfault. count the times "step" was
>  > issued since gdb will not be able to find the source line number.
>
> Breakpoint 17, init_module_2 (module=0x8221ca0) at ../src/spvw.d:2066
> 2066      (*module->initfunction1)(module);
> (gdb) p /x *module
> $1 = {name = 0x817112d, stab = 0x8222974, stab_size = 0x8221e40,
>   otab = 0x8240800, otab_size = 0x8221e44, initialized = 0x1,
>   stab_initdata = 0x8221e60, otab_initdata = 0x8222180,
>   initfunction1 = 0x80731d8, initfunction2 = 0x80731cc,
>   finifunction = 0x8073408, next = 0x8221cd0}
> (gdb) step
> module__syscalls__init_function_1 (module=0x8221ca0)
>     at /root/clisp/modules/syscalls/calls.c:6359
> Line number 6359 out of range; /root/clisp/modules/syscalls/calls.c has 5492
> lines.
> (gdb) help step
> Step program until it reaches a different source line.
> Argument N means do this N times (or till program stops for another reason).
> (gdb) step
> sigsegv_handler (sig=11, sc=
>       {gs = 51, __gsh = 0, fs = 0, __fsh = 0, es = 123, __esh = 49216, ds =
> 123, __dsh = 0, edi = 1120484, esi = 136579072, ebp = 3220833528, esp =
> 3220833492, ebx = 136451968, edx = 545438158, ecx = 1121592, eax = 1, trapno
> = 14, err = 6, eip = 134689291, cs = 115, __csh = 0, eflags = 66071,
> esp_at_signal = 3220833492, ss = 123, __ssh = 0, fpstate = 0xbffa42dc,
> oldmask = 134244399, cr2 = 1}) at handler-unix.c:125
> 125     {

So it looks like segfault happens on first pushSTACK in
module__syscalls__init_function_1 (calls.m.c):
pushSTACK(O(object_Kmethod));

It's either pushSTACK() or O(object_Kmethod). pushSTACK() with MT uses
per thread (gcc __thread) variable - but I do not see relation here.
O(xxx) also does not seem "dangerous". Sam?

btw: what happens if you exclude syscall module from command line
argument (leaving all others)? is there segfault? I do not think this
is module related (i see i18n is initialized).

In case it matters, the history of this executable:
starting with cvs from ~4AM PDT 10/5
[2009-10-05 10:52:03 root@... ~/clisp] 
$ ./configure --with-threads=POSIX_THREADS --with-module=rawsock --with-dynamic-modules=yes build-mt-yes 
[2009-10-05 10:54:21 root@... ~/clisp/build-mt-yes] 
$ make 
Then a cvs update was done ~4AM PDT 10/6, then after editing
Makefile, another make today.

 > btw: what happens if you exclude syscall module from command line
 > argument (leaving all others)? is there segfault? I do not think this
 > is module related (i see i18n is initialized).
$ gdb base/lisp.run  
 ...
(gdb) set args -B . -M base/lispinit.mem -norc -q 
(gdb) delete 
Delete all breakpoints? (y or n) y 
(gdb) handle SIGSEGV nostop noprint 
Signal        Stop      Print   Pass to program Description 
SIGSEGV       No        No      Yes             Segmentation fault 
(gdb) break spvw.d:2066 
Breakpoint 17 at 0x8088ceb: file ../src/spvw.d, line 2066. 
(gdb) run 
Starting program: /root/clisp/build-mt-yes/base/lisp.run -B . -M base/lispinit.mem -norc -q 
Reading symbols from shared object read from target memory...done. 
Loaded system supplied DSO at 0x6dc000 
[Thread debugging using libthread_db enabled] 
[New Thread 1120480 (LWP 8298)] 
[Switching to Thread 1120480 (LWP 8298)] 
 
Breakpoint 17, init_module_2 (module=0x8221c70) at ../src/spvw.d:2066 
2066      (*module->initfunction1)(module); 
(gdb) continue 
Continuing. 
 
Breakpoint 17, init_module_2 (module=0x8221ca0) at ../src/spvw.d:2066 
2066      (*module->initfunction1)(module); 
(gdb) p /x *module 
$1 = {name = 0x817112d, stab = 0x8222974, stab_size = 0x8221e40,  
  otab = 0x8240800, otab_size = 0x8221e44, initialized = 0x1,  
  stab_initdata = 0x8221e60, otab_initdata = 0x8222180,  
  initfunction1 = 0x80731d8, initfunction2 = 0x80731cc,  
  finifunction = 0x8073408, next = 0x8221cd0} 
(gdb) step 
module__syscalls__init_function_1 (module=0x8221ca0) 
    at /root/clisp/modules/syscalls/calls.c:6359 
Line number 6359 out of range; /root/clisp/modules/syscalls/calls.c has 5492 lines.  
(gdb) step 
sigsegv_handler (sig=11, sc= 
      {gs = 51, __gsh = 0, fs = 0, __fsh = 0, es = 123, __esh = 49216, ds = 123, __dsh = 0, edi = 1120484, esi = 136579072, ebp = 3219653624, esp = 3219653588, ebx = 136451968, edx = 562403790, ecx = 1121592, eax = 1, trapno = 14, err = 6, eip = 134689291, cs = 115, __csh = 0, eflags = 66071, esp_at_signal = 3219653588, ss = 123, __ssh = 0, fpstate = 0xbfe841dc, oldmask = 134244399, cr2 = 1}) at handler-unix.c:125 
125     { 
(gdb)

On 10/6/09, Vladimir Tzankov <vtzankov@...> wrote:
> So it looks like segfault happens on first pushSTACK in
> module__syscalls__init_function_1 (calls.m.c):
> pushSTACK(O(object_Kmethod));
>
> It's either pushSTACK() or O(object_Kmethod). pushSTACK() with MT uses
> per thread (gcc __thread) variable - but I do not see relation here.

Can you configure and built with -DUSE_CUSTOM_TLS=0 added to CFLAGS?
During the build you will get warnings: "USE_CUSTOM_TLS overrides the
compiler per_thread support." and the resulting executable will be
quite slower.
If segfault goes away with this built - it means something is wrong
with __thread variables.

On 10/7/09, Vladimir Tzankov <vtzankov@...> wrote:
> On 10/6/09, Vladimir Tzankov <vtzankov@...> wrote:
>> So it looks like segfault happens on first pushSTACK in
>> module__syscalls__init_function_1 (calls.m.c):
>> pushSTACK(O(object_Kmethod));
>>
>> It's either pushSTACK() or O(object_Kmethod). pushSTACK() with MT uses
>> per thread (gcc __thread) variable - but I do not see relation here.
>
> Can you configure and built with -DUSE_CUSTOM_TLS=0 added to CFLAGS?

oops - sorry. -DUSE_CUSTOM_TLS=1 not 0

Vladimir Tzankov writes:

 > Can you configure and built with -DUSE_CUSTOM_TLS=0 added to CFLAGS?
I can't seem to add that to the configure line, so I configure as
before
 $ ./configure --with-threads=POSIX_THREADS --with-module=rawsock --with-dynamic-modules=yes build-mt-yes-tls0
and then change build-mt-yes-tls0/Makefile:
 CFLAGS = -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type-Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -pthread -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_FFI -DDYNAMIC_MODULES -I. -DUSE_CUSTOM_TLS=1 

then make, which does complete successfully.

 > During the build you will get warnings: "USE_CUSTOM_TLS overrides the
 > compiler per_thread support." and the resulting executable will be
 > quite slower.

 > If segfault goes away with this built - it means something is wrong
 > with __thread variables.
But how is this related to dynamic modules?

 > oops - sorry. -DUSE_CUSTOM_TLS=1 not 0

On 10/7/09, Don Cohen <don-sourceforge-xxz@...> wrote:
>  $ ./configure --with-threads=POSIX_THREADS --with-module=rawsock
> --with-dynamic-modules=yes build-mt-yes-tls0
> and then change build-mt-yes-tls0/Makefile:
>  CFLAGS = -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit
> -Wreturn-type-Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral
> -O2 -fexpensive-optimizations -falign-functions=4 -pthread -DENABLE_UNICODE
> -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_FFI -DDYNAMIC_MODULES -I.
> -DUSE_CUSTOM_TLS=1
>
> then make, which does complete successfully.
>
>  > During the build you will get warnings: "USE_CUSTOM_TLS overrides the
>  > compiler per_thread support." and the resulting executable will be
>  > quite slower.
>
>  > If segfault goes away with this built - it means something is wrong
>  > with __thread variables.
> But how is this related to dynamic modules?

I do not know. It's either gcc bug or something I am not aware of.
Will try to find out (-DUSE_CUSTOM_TLS=1 is really slow).

Vladimir Tzankov writes:

 > I do not know. It's either gcc bug or something I am not aware of.
 > Will try to find out (-DUSE_CUSTOM_TLS=1 is really slow).
It sounded like you had a plan for finding out.
Is there an expected time frame?  I'm not trying to hurry you, just
want to know when to figure that it has been forgotten.

I don't know whether there's a way to join two mail threads, but it
seems to me that "Re: distant backward compatibility" is now
sufficiently related that it and this ought to be discussed together.
In particular, I have now tried the following experiments on both
machines with the following results:

tls                linux 2.4.18-14                linux 2.6.17-1.2142_FC4
 none    undefined symbol: _current_thread        SIGSEGV cannot be cured
 1                 worked                             worked
 2       clisp.h:4468: request for member cache...    worked
 3       [interpreted.mem] Segmentation fault         worked

There's also another variable, dynamic modules.  
That has only been tried on FC4.  Should I try it on the other machine?
I begin to wonder whether all of this is one bug or many.

Evidently the default tls value is none of {1,2,3}.
So it might be useful to understand how the default performs in
relation to the description you sent:
   USE_CUSTOM_TLS={1,2,3}
     1 - using xthread_key_get/set - slowest one (and probably safest)
     2 - using slightly modified version of TLS found in Boehm GC for C/C++.
     3 - using full page map of address space (4 MB).
     Basically it is trade-off between performance/memory usage:
     {1} - xthread_key_get/set is 200-500% slower then native compiler TLS.
     {2} is about 50-100% slower than compiler TLS support and uses just 8 KB.
     {3} is almost as fast as single threaded and compiler TLS but uses 4 MB.
BTW, doesn't "full page map" depend on things like the VM size and the
page size?  TLS=thread local storage, right?  I don't see what that
could have to do with page maps.  Where can I find out about these
various implementations?

I think you've now seen all of the errors listed above except tls3, 
which is below.

gcc -DUSE_CUSTOM_TLS=3 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -pthread -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_FFI -DDYNAMIC_MODULES -I.  -Wl,-export-dynamic spvw.o spvwtabf.o spvwtabs.o spvwtabo.o eval.o control.o encoding.o pathname.o stream.o socket.o io.o funarg.o array.o hashtabl.o list.o package.o record.o weak.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 zthread.o built.o ari80386.o modules.o -lreadline -lncurses -ldl /usr/local/lib/libavcall.a /usr/local/lib/libcallback.a  -L/usr/local/lib -lsigsegv -lc libgnu_cl.a -o lisp.run
./lisp.run -B . -N locale -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc -m 2MW -lp ../src/ -x '(and (load "../src/init.lisp") (sys::%saveinitmem) (ext::exit)) (ext::exit t)'
make: *** [interpreted.mem] Segmentation fault

Don Cohen writes:

 > tls                linux 2.4.18-14                linux 2.6.17-1.2142_FC4
 >  none    undefined symbol: _current_thread        SIGSEGV cannot be cured
 >  1                 worked                             worked
well, appeared to work other than the freeze
 >  2       clisp.h:4468: request for member cache...    worked
now a new error, clisp.h:739: parse error before '*' token
 >  3       [interpreted.mem] Segmentation fault         worked

Back on FC4 I have now tried make check from the tls 1 and 3 builds.

(LET* ((COUNT 300) (PA (MAKE-PACKAGE (SYMBOL-NAME (GENSYM "MT-TEST-")) :USE NIL)) (TL (LOOP :FOR I :FROM 1 :TO COUNT :COLLECT (LET ((I I)) (MAKE-TEST-THREAD (LAMBDA NIL (INTERN (PRIN1-TO-STRING I) PA))))))) (LOOP :WHILE (SOME #'THREAD-ACTIVE-P TL) :DO (SLEEP 0.1)) (LET ((I 0)) (DO-SYMBOLS (S PA) (DECLARE (IGNORE S)) (INCF I)) (ASSERT (= I COUNT))) (SETQ TL (LOOP :FOR I :FROM 1 :TO COUNT :COLLECT (LET ((I I)) (MAKE-TEST-THREAD (LAMBDA NIL (UNINTERN (FIND-SYMBOL (PRIN1-TO-STRING I) PA) PA)))))) (LOOP :WHILE (SOME #'THREAD-ACTIVE-P TL) :DO (SLEEP 0.1)) (LET ((I 0)) (DO-SYMBOLS (S PA) (DECLARE (IGNORE S)) (INCF I)) (ASSERT (ZEROP I))) (DELETE-PACKAGE PA)) 
 
*** - handle_fault error2 ! address = 0x68387dd0 not in [0x683a84b8,0x684bc000) ! 
SIGSEGV cannot be cured. Fault address = 0x68387dd0. 
GC count: 1158 
Space collected by GC: 0 780689160 
Run time: 107 162696 
Real time: 273 138076 
GC time: 23 769446 
Permanently allocated: 107256 bytes. 
Currently in use: 4681080 bytes. 
Free space: 814014 bytes. 
make[1]: *** [parallel] Segmentation fault 
make[1]: Leaving directory `/root/clisp/build-mt-tls3/tests' 
make: *** [check-tests-parallel] Error 2 


(SPECIAL X)) X))) 
WARNING : 
variable X is not used. 
Misspelled or missing IGNORE declaration? 
EQL-OK: :SPECIAL 
RUN-TEST: finished "bind" (0 errors out of 72 tests) 
 
*** - handle_fault error2 ! address = 0x6836f8b0 not in [0x6838bb38,0x6849e000) ! 
SIGSEGV cannot be cured. Fault address = 0x6836f8b0. 
GC count: 1011 
Space collected by GC: 0 728027160 
Run time: 172 906805 
Real time: 339 572277 
GC time: 17 373093 
Permanently allocated: 107256 bytes. 
Currently in use: 4928632 bytes. 
Free space: 264756 bytes. 
make[1]: *** [parallel] Segmentation fault 
make[1]: Leaving directory `/root/clisp/build-mt-tls1/tests' 
make: *** [check-tests-parallel] Error 2 


make check seems not to get these errors in clisp/build-mt-no
(That's --with-dynamic-modules=no)

On 10/8/09, Don Cohen <don-sourceforge-xxz@...> wrote:
> Don Cohen writes:
> Back on FC4 I have now tried make check from the tls 1 and 3 builds.
>
> (LET* ((COUNT 300) (PA (MAKE-PACKAGE (SYMBOL-NAME (GENSYM "MT-TEST-")) :USE
> NIL)) (TL (LOOP :FOR I :FROM 1 :TO COUNT :COLLECT (LET ((I I))
> (MAKE-TEST-THREAD (LAMBDA NIL (INTERN (PRIN1-TO-STRING I) PA))))))) (LOOP
> :WHILE (SOME #'THREAD-ACTIVE-P TL) :DO (SLEEP 0.1)) (LET ((I 0)) (DO-SYMBOLS
> (S PA) (DECLARE (IGNORE S)) (INCF I)) (ASSERT (= I COUNT))) (SETQ TL (LOOP
> :FOR I :FROM 1 :TO COUNT :COLLECT (LET ((I I)) (MAKE-TEST-THREAD (LAMBDA NIL
> (UNINTERN (FIND-SYMBOL (PRIN1-TO-STRING I) PA) PA)))))) (LOOP :WHILE (SOME
> #'THREAD-ACTIVE-P TL) :DO (SLEEP 0.1)) (LET ((I 0)) (DO-SYMBOLS (S PA)
> (DECLARE (IGNORE S)) (INCF I)) (ASSERT (ZEROP I))) (DELETE-PACKAGE PA))
>
> *** - handle_fault error2 ! address = 0x68387dd0 not in
> [0x683a84b8,0x684bc000) !
> SIGSEGV cannot be cured. Fault address = 0x68387dd0.

hmm, this is bad.
I do not get segault here (and have run it many times :)) - will try
harder to stress test it.

Vladimir Tzankov writes:

 > hmm, this is bad.
 > I do not get segault here (and have run it many times :)) - will try
 > harder to stress test it.
I now turn to the newest machine on which MT builds have been working
all along.  There make check ends with this.

 EQUALP-OK: #(A B C D E)
 (SYSTEM::COERCED-SUBSEQ '(A B C D E F) '(OR (VECTOR T 5) (VECTOR T
 10)))
 [SIMPLE-TYPE-ERROR]: 
 EQL-OK: T
 (EQ (CLASS-OF NIL) (FIND-CLASS 'NULL))
 SYSTEM::COERCED-SUBSEQ: the result #1=#(A B C D E F) is not of type
 #2=(OR (VECTOR T 5) (VECTOR T 10))


 *** - handle_fault error2 ! address = 0x0 not in
 [0x3341a8000,0x3343b2018) !
 EQL-OK: T
 SIGSEGV cannot be cured. Fault address = 0x0.
 GC count: 25
 Space collected by GC: 18563800
 Run time: 2 856564
 Real time: 3 109926
 GC time: 0 100977
 Permanently allocated: 176520 bytes.
 Currently in use: 3693280 bytes.
 Free space: 586706 bytes.
 make[1]: *** [parallel] Segmentation fault
 make[1]: Leaving directory `/root/clisp/build-mt/tests'
 make: *** [check-tests-parallel] Error 2

I've not normally been doing make check.  
On what systems do you normally run it?

On 10/9/09, Don Cohen <don-sourceforge-xxz@...> wrote:
>  EQUALP-OK: #(A B C D E)
>  (SYSTEM::COERCED-SUBSEQ '(A B C D E F) '(OR (VECTOR T 5) (VECTOR T
>  10)))
>  [SIMPLE-TYPE-ERROR]:
>  EQL-OK: T
>  (EQ (CLASS-OF NIL) (FIND-CLASS 'NULL))
>  SYSTEM::COERCED-SUBSEQ: the result #1=#(A B C D E F) is not of type
>  #2=(OR (VECTOR T 5) (VECTOR T 10))
>
>
>  *** - handle_fault error2 ! address = 0x0 not in
>  [0x3341a8000,0x3343b2018) !
>
> I've not normally been doing make check.
> On what systems do you normally run it

Probably this is in make check-tests-parallel (part of make check).
Currently when I do make check-tests  - I exclude mop and clos tests -
they may cause segfaults (still no locking there).

Vladimir Tzankov writes:

 > Probably this is in make check-tests-parallel (part of make check).
 > Currently when I do make check-tests  - I exclude mop and clos tests -
 > they may cause segfaults (still no locking there).
Tell me how to do that and I'll try it.
Also can you tell me how to run the same tests for an arbitrary
clisp image?

I assume this belongs on the devel list.
I simply leave all of the text of the last message in order to keep
as much as possible of what would otherwise have been lost.

Vladimir Tzankov writes:
 > On 10/15/09, Don Cohen <don-sourceforge-xxz@...> wrote:
 > > I guess you mean something like this:
 > >     #+(or (and (not mt) CLISP) ALLEGRO CMU OpenMCL LISPWORKS) ("clos")
 > >     #+(or (and (not mt) CLISP) ALLEGRO OpenMCL LISPWORKS) ("mop")
 > yes
 > > Even so,
 > >  make check-tests-parallel
 > > ends with
 > >  (ALPHANUMERICP #\A)
 > >  EQL-OK: T
 > >  (ALPHANUMERICP 1)
 > >  *** - handle_fault error2 ! address = 0x0 not in [0x334f14000,0x33511e018)
 > > ...
 > > How can one go about debugging this?
 > > Will a transcript help?
 > 
 > There are other places where clos is used and is not guarded in any
 > way (of course the problem above can be different).
 > Debugging such cases is not trivial and there is no simple/single way
 > to approach them. Most probably something in the heap is corrupted
 > (due to concurrent modifications) and the segfault happens during GC
 > or after it on unrelated to the problem place.
 > 
 > How frequently the above happens when you run "make
 > check-tests-parallel" and which tests were running at the time of
 > segfault (check *.erg files in tests/ directory)?
So far I've done make check-tests-parallel once.  I can try again if 
you like.
 ...
ok, just tried again, ended with

 EQUALP-OK: EQUALP-OK: ##(2AY( (A# \4a  A# \bC  #9\ cA)  D( #2\ d3 )#\
 e #\f) (#\g #\h #\i))
 ((REMOVEPROGN  '(A DEF-CALL-OUT'( AC-SELF  1( :BNAME  A"
 ffi_identity2" )A )( ::ARGUMENTSSTART  (1FIRST) 
 (C-ARRAY-PTR UINT8))) (:RETURN-TYPE (C-PTR (C-ARRAY CHARACTER (3 3))))
 (:LANGUAGE :STDC)) (ARRAY-DIMENSIONS (C-SELF #(230 151 165 230 156 172
 232 170 158))))
 EQUAL-OK: [(SIMPLE-CHARSET-TYPE-ERRORA]:  1 B 2)
 FFI::FOREIGN-CALL-OUT: Invalid byte #xE6 in CHARSET:ASCII conversion


 *** - handle_fault error2 ! address = 0x0 not in
 [0x334d92000,0x334fc9478) !
 SIGSEGV cannot be cured. Fault address = 0x0.
 GC count: 36
 Space collected by GC: 28385832
 Run time: 5 756124
 Real time: 5 641654
 GC time: 0 125974
 Permanently allocated: 176520 bytes.
 Currently in use: 3791016 bytes.
 Free space: 450506 bytes.
 make[1]: *** [parallel] Segmentation fault
 make[1]: Leaving directory `/root/clisp/build-mt/tests'
 make: *** [check-tests-parallel] Error 2

All of these erg's are size 0.
 $ ls tests/*.erg
 tests/alltest.erg  tests/characters.erg  tests/encoding.erg tests/ffi.erg

On 10/15/09, Don Cohen <don-sourceforge-xxz@...> wrote:
> So far I've done make check-tests-parallel once.  I can try again if
> you like.
>  ...
> ok, just tried again, ended with
> ...
>  *** - handle_fault error2 ! address = 0x0 not in
> ...
> All of these erg's are size 0.
>  $ ls tests/*.erg
>  tests/alltest.erg  tests/characters.erg  tests/encoding.erg tests/ffi.erg

4 erg files - usually they should be 5. It means that thread has just
exited (or is exiting now). Will check thread cleanup code for some
kind of races.
Can you try few more times and count the erg files at segfault?

Vladimir Tzankov writes:
 > 4 erg files - usually they should be 5. It means that thread has just
 > exited (or is exiting now). Will check thread cleanup code for some
 > kind of races.
 > Can you try few more times and count the erg files at segfault?
EQL-OK: ERROR
(FOREIGN-VARIABLE FM (PARSE-C-TYPE 'C-POINTER) :NAME 123)
[SIMPLE-TYPE-ERROR]: FOREIGN-VARIABLE: argument 123 is not a string

*** - handle_fault error2 ! address = 0x0 not in
[0x333e9f000,0x334130ea0) !
SIGSEGV cannot be cured. Fault address = 0x0.
 ...
$ ls -l tests/*.erg
-rw-r--r--. 1 root root 0 2009-10-16 04:10 tests/characters.erg
-rw-r--r--. 1 root root 0 2009-10-16 04:10 tests/encoding.erg
-rw-r--r--. 1 root root 0 2009-10-16 04:10 tests/ffi.erg
-rw-r--r--. 1 root root 0 2009-10-16 04:10 tests/hashlong.erg


EQL-OK: (TFUNCALL
 FPCALLBACK -7.5d0)

*** - handle_fault error2 ! address = 0x0 not in
[0x334c0f000,0x334e19018) !
SIGSEGV cannot be cured. Fault address = 0x0.
 ...
$ ls -l tests/*.erg
-rw-r--r--. 1 root root 177 2009-10-16 04:13 tests/alltest.erg
-rw-r--r--. 1 root root   0 2009-10-16 04:13 tests/characters.erg
-rw-r--r--. 1 root root   0 2009-10-16 04:13 tests/encoding.erg
-rw-r--r--. 1 root root   0 2009-10-16 04:13 tests/ext-clisp.erg
-rw-r--r--. 1 root root   0 2009-10-16 04:13 tests/ffi.erg


[SIMPLE-ERROR]: The form (TRUNCATE 3.2 2) yielded 1 ; 1.2 ,
that's not of type (VALUES FLOAT INTEGER).
EQL-OK: ERROR

*** - handle_fault error2 ! address = 0x0 not in
[0x3345f8000,0x334829b80) !
SIGSEGV cannot be cured. Fault address = 0x0.
 ...
$ ls -l tests/*.erg
-rw-r--r--. 1 root root 0 2009-10-16 04:15 tests/alltest.erg
-rw-r--r--. 1 root root 0 2009-10-16 04:15 tests/characters.erg
-rw-r--r--. 1 root root 0 2009-10-16 04:15 tests/encoding.erg
-rw-r--r--. 1 root root 0 2009-10-16 04:15 tests/eval20.erg
-rw-r--r--. 1 root root 0 2009-10-16 04:15 tests/ext-clisp.erg

Since I was trying
 make check-tests-parallel
on the new (fc11) 64 bit dual core machine, it occurred to me that I
might as well also try it on the old 32 bit single core machine where
I cannot build from
 ./configure --with-threads=POSIX_THREADS --with-module=rawsock build-mt 
but I can build from
 ./configure --with-threads=POSIX_THREADS --with-module=rawsock \
  --with-dynamic-modules=no build-mt-no
After changing #+ ... clisp to (and (not mt) clisp) for mop and clos
 make check-tests-parallel
ends with

 ...
 EQL-OK: MAKE-TEST-THREAD 
 (LET* ((MU (MAKE-MUTEX :NAME "hash-table lock")) (HT
 (MAKE-HASH-TABLE)) (TL (LOO\
 P :REPEAT 300 :COLLECT (MAKE-TEST-THREAD (LAMBDA NIL (MUTEX-LOCK MU)
 (INCF (GETH\
 ASH 1 HT 0)) (MUTEX-UNLOCK MU)))))) (LOOP :WHILE (SOME
 #'THREAD-ACTIVE-P TL) :DO\
  (SLEEP 0.1)) (GETHASH 1 HT)) 

 *** - handle_fault error2 ! address = 0x680b46a8 not in [0x680be758,0x6814d000) ! 
 SIGSEGV cannot be cured. Fault address = 0x680b46a8. 
 GC count: 1217 
 Space collected by GC: 0 677686576 
 Run time: 83 289205 
 Real time: 165 506304 
 GC time: 16 965051 
 Permanently allocated: 107104 bytes. 
 Currently in use: 3389440 bytes. 
 Free space: 461140 bytes. 
 make[1]: *** [parallel] Segmentation fault 
 make[1]: Leaving directory `/root/clisp/build-mt-no/tests' 
 make: *** [check-tests-parallel] Error 2 
 [2009-10-16 10:58:13 root@... ~/clisp/build-mt-no] 
 $ ls -l tests/*.erg 
 -rw-r--r--  1 root root 63 Oct 16 10:57 tests/mt.erg 
 -rw-r--r--  1 root root  0 Oct 16 10:57 tests/time.erg 
 [2009-10-16 10:58:29 root@... ~/clisp/build-mt-no] 


next try
 ...
 [SIMPLE-PACKAGE-ERROR]: MAKE-PACKAGE: a package with name "CL" already
 exists. 

 [SIMPLE-PACKAGE-ERROR]:  
 *** - handle_fault error2 ! address = 0x684ed410 not in [0x684f8ae8,0x6858b000) ! 
 SIGSEGV cannot be cured. Fault address = 0x684ed410. 
 GC count: 1297 
 Space collected by GC: 0 711202304 
 Run time: 87 601474 
 Real time: 183 190549 
 GC time: 17 581103 
 Permanently allocated: 107104 bytes. 
 Currently in use: 3353056 bytes. 
 Free space: 575090 bytes. 
 make[1]: *** [parallel] Segmentation fault 
 make[1]: Leaving directory `/root/clisp/build-mt-no/tests' 
 make: *** [check-tests-parallel] Error 2 
 [2009-10-16 11:03:08 root@... ~/clisp/build-mt-no] 
 $ ls -l tests/*.erg 
 -rw-r--r--  1 root root 63 Oct 16 11:01 tests/mt.erg 
 -rw-r--r--  1 root root  0 Oct 16 11:02 tests/restarts.erg 
 -rw-r--r--  1 root root  0 Oct 16 11:01 tests/time.erg 
 [2009-10-16 11:03:27 root@... ~/clisp/build-mt-no] 

next try:
 ...
 Test passed. 
 make[1]: Leaving directory `/root/clisp/build-mt-no/tests' 
 [2009-10-16 11:08:33 root@... ~/clisp/build-mt-no] 
 $ ls -l tests/*.erg 
 ls: tests/*.erg: No such file or directory 
 [2009-10-16 11:10:55 root@... ~/clisp/build-mt-no] 

(nice to see that it can happen, btw)

next try:
 ...
 EQL-OK: :SPECIAL 
 RUN-TEST: finished "bind" (0 errors out of 72 tests) 

 *** - handle_fault error2 ! address = 0x68639c38 not in [0x68648d28,0x686d5000) ! 
 SIGSEGV cannot be cured. Fault address = 0x68639c38. 
 GC count: 1105 
 Space collected by GC: 0 700143888 
 Run time: 79 860990 
 Real time: 157 436104 
 GC time: 12 812800 
 Permanently allocated: 107104 bytes. 
 Currently in use: 3353600 bytes. 
 Free space: 526148 bytes. 
 make[1]: *** [parallel] Segmentation fault 
 make[1]: Leaving directory `/root/clisp/build-mt-no/tests' 
 make: *** [check-tests-parallel] Error 2 
 [2009-10-16 11:14:57 root@... ~/clisp/build-mt-no] 
 $ ls -l tests/*.erg 
 -rw-r--r--  1 root root 0 Oct 16 11:14 tests/mt.erg 
 -rw-r--r--  1 root root 0 Oct 16 11:14 tests/time.erg 
 [2009-10-16 11:15:23 root@... ~/clisp/build-mt-no] 

I hope this is useful.  Let me know what else you'd like me to try.

On 10/16/09, Don Cohen <don-sourceforge-xxz@...> wrote:
> Since I was trying
>  make check-tests-parallel
> on the new (fc11) 64 bit dual core machine, it occurred to me that I
> might as well also try it on the old 32 bit single core machine.

On 64 bit I reproduce segfaults - working on it now.
However on 32 bit (i386 & ppc) - I cannot (that's not to say there is
no problem - probably it is the same as on 64 bit builds but for some
reason on my test machines it does not happen).
Thanks.

Vladimir