[Axiom-developer] FW: [Axiom-mail] Re: noweb

[Page, Bill]

Camm,

I have encountered the error message:

  NULL_OR_ON_C_STACK macro invalid

again while building gcl-2.6.8pre (contain in the current Axiom
distribution), on the axiom-developer.org shared virtual server
with option --enable-maxpage=256*1024. As before, the build of
gcl and of Axiom completes normally if I change the gclopts to
--enable-maxpage=128*1024. Tim did say that he was going to
revert to the smaller value

http://lists.gnu.org/archive/html/axiom-developer/2005-10/msg00392.html

but the current build still uses 256*1024.

I am wondering whether anything in the forth coming gcl-2.7
might help to eliminate this problem? Did you manage to "relax the
power of two constraint"?

----------

Background:

http://lists.gnu.org/archive/html/axiom-developer/2005-10/msg00396.html

> Bill, here is the problem -- Redhat 9 is apparently placing the
> stack within the first 1Gb of memory, but you are requesting this
> amount for your heap.  GCL won't (or tries not to) allow the head
> to overrun the stack: 
>
> p/x -1073750720   /* This is my cstack address.  Just built 2.6.7 with
*/
> $1 = 0xbfffdd40   /* 256*1024 maxpages just fine*/
> (gdb) p/x 1073738356 /* here is yours */
> $2 = 0x3ffff274
> (gdb) p/x 256*1024*4096+0x8000000
> $3 = 0x48000000   /* here is the end of your requested heap */
> (gdb) 
>
> In all of the machines I've looked at, this is about the worst stack
> placement I've seen.  Is this 'enterprise' or 'normal'?   I thought
> the former had a sophisticated mechanism to push the stack and the
> shared memory area as high up in memory as possible.
>
> I know of no way to change this short of getting a different Linux
> kernel, where the issue should be addressable.
>
> One thing we could do is relax the power of two constraint on
> maxpages if a lesser amount would suffice.

-------

We are currently using linux kernel 2.6.16.14. Could you explain
what you mean by "the issue should be addressable"? How could I
go about addressing it, given that this is a share virtual server?

I was wondering if it might be possible to change the
NULL_OR_ON_C_STACK macro to be something like that proposed by
Mike Thomas for Windows:

http://lists.gnu.org/archive/html/gcl-devel/2005-12/msg00091.html

Actually, it seems that for Axiom we often do need more memory.
Anything you can suggest here would be appreciated.

Regards,
Bill Page.

-----Original Message-----
From: Page, Bill [mailto:address@hidden 
Sent: Tuesday, August 08, 2006 6:43 PM
To: address@hidden
Cc: address@hidden; address@hidden
Subject: RE: [Axiom-mail] Re: noweb

On Tuesday, August 08, 2006 5:56 PM in axiom-mail Gaby wrote:
> ... 
> I need to get this Autoconf stuff move on.
>

I think you are doing a great job! Thanks.
 
> Did you test build-improvements branch recently?
> 

I just did:

  svn update
  ./configure
  make

on the axiom-developer.org server and got the following
build failure:

checking build system type... i686-pc-linux
checking host system type... i686-pc-linux
checking target system type... i686-pc-linux
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
checking for gtar... gtar
checking for gpatch... no
checking for patch... patch
checking for make... make
checking for ranlib... ranlib
checking for touch... touch
checking how to run the C preprocessor... gcc -E
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include

...

touch raw_pre_gcl_map
gcc -o raw_pre_gcl
/home/page/axiom.build-improvements/obj/linux/lib/cfuns-c.o
/home/page/axiom.build-improvements/obj/linux/lib/sockio-c.o \
        -L.  -Wl,-Map raw_pre_gcl_map   -lpre_gcl -lm  -lgmp
/usr/local/lib/libbfd.a /usr/local/lib/libiberty.a -lreadline -lncurses
-lc -lgclp /home/page/axiom.build-improvements/obj/linux/lib/libspad.a
cat init_pre_gcl.lsp.tmp | sed \
        -e "address@hidden@#(`cat ../majvers`.`cat ../minvers`) `date`#1" \
        -e "address@hidden@#`cat ../minvers | cut -f2 -d.`#1" \
        -e "address@hidden@#`cat ../minvers | cut -f1 -d.`#1" \
        -e "address@hidden@#`cat ../majvers`#1" \
        -e "address@hidden@#\"gcc -c -Wall -DVOL=volatile -fsigned-char -pipe
\"#1" \
        -e "address@hidden@#\"gcc -o \"#1" \
        -e "address@hidden@#\"   -lpre_gcl -lm  -lgmp
/usr/local/lib/libbfd.a /usr/local/lib/libiberty.a -lreadline -lncurses
-lc -lgclp /home/page/axiom.build-improvements/obj/linux/lib/libspad.a
\"#1" \
        -e "address@hidden@#\"-O3 -fomit-frame-pointer\"#1" \
        -e "address@hidden@#\"-O\"#1" \
        -e "address@hidden@#\"init_pre_gcl.lsp\"#1" >init_pre_gcl.lsp
cp init_pre_gcl.lsp foo
echo " (in-package \"USER\")(system:save-system \"saved_pre_gcl\")"
>>foo
/home/page/axiom.build-improvements/lsp/gcl-2.6.8pre/unixport/raw_pre_gc
l /home/page/axiom.build-improvements/lsp/gcl-2.6.8pre/unixport/ -libdir
/home/page/axiom.build-improvements/lsp/gcl-2.6.8pre/ < foo
GCL (GNU Common Lisp)  April 1994  262144 pages

Unrecoverable error: NULL_OR_ON_C_STACK macro invalid.
make[5]: *** [saved_pre_gcl] Error 134
rm raw_pre_gcl init_pre_gcl.lsp
make[5]: Leaving directory
`/home/page/axiom.build-improvements/lsp/gcl-2.6.8pre/unixport'
make[4]: *** [unixport/saved_pre_gcl] Error 2
make[4]: Leaving directory
`/home/page/axiom.build-improvements/lsp/gcl-2.6.8pre'
/bin/sh: line 1: unixport/saved_gcl: No such file or directory
make[3]: *** [gcldir] Error 127
make[3]: Leaving directory `/home/page/axiom.build-improvements/lsp'
make[2]: *** [lspdir] Error 2
make[2]: Leaving directory `/home/page/axiom.build-improvements'
make[1]: *** [do-all] Error 2
make[1]: Leaving directory `/home/page/axiom.build-improvements'
make: *** [all] Error 2

---------

axiom.developer.org is

$ uname -a
Linux axiom-developer.org 2.6.16.14-RH202rc19 #3 SMP
  Sun May 7 18:39:41 CDT 2006 i686 i686 i386 GNU/Linux

running as a shared virtual host with

$ gcc --version
gcc (GCC) 3.4.4

This is a failure during the sub-build of GCL but the cause is
not immediately clear to me.

axiom.build-improvements/lsp/gcl-2.6.8pre/config.status shows:

# ./configure  '--enable-vssize=65536*2' --enable-statsysbfd
  '--enable-maxpage=256*1024'

These options for the gcl build are different from the
axiom--main--1-patch-49 that builds successfully on this
system:

# ./configure  '--enable-vssize=65536*2' --enable-statsysbfd
  '--enable-maxpage=128*1024'

I previously reported the message "NULL_OR_ON_C_STACK macro invalid"
to Camm MacQuire when using the --enable-maxpage=256*1024 option
on this system but he was not able to suggest a solution. The
suspicion is that this has something to do with memory management
on a linux virtual host.

I will repeat the build using --enable-maxpage=128*1024. Maybe we
need a way to conveniently pass build options through ./configure
to the gcl ./configure?

If you like I can send you the full build log or other intermediate
files.

Regards,
Bill Page.