[Gcl-devel] Re: FW: [Axiom-mail] Re: noweb

[Camm Maguire]

Greetings!

"Page, Bill" <address@hidden> writes:

> 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"?
> 

The power of two constraint remains in 2.7, hopefully for only a short
time.  Can I log in to look at this?

Take care,


> ----------
> 
> 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.
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah