[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] Re: FW: [Axiom-mail] Re: noweb
From: |
Camm Maguire |
Subject: |
[Axiom-developer] Re: FW: [Axiom-mail] Re: noweb |
Date: |
09 Aug 2006 19:21:08 -0400 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
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
- [Axiom-developer] FW: [Axiom-mail] Re: noweb, Page, Bill, 2006/08/08
- [Axiom-developer] Re: FW: [Axiom-mail] Re: noweb,
Camm Maguire <=
- [Axiom-developer] NULL_OR_ON_C_STACK macro invalid (was: noweb), Page, Bill, 2006/08/09
- [Axiom-developer] Re: NULL_OR_ON_C_STACK macro invalid (was: noweb), Camm Maguire, 2006/08/10
- [Axiom-developer] Re: NULL_OR_ON_C_STACK macro invalid (was: noweb), Camm Maguire, 2006/08/10
- [Axiom-developer] Re: NULL_OR_ON_C_STACK macro invalid (was: noweb), Gabriel Dos Reis, 2006/08/10
- [Axiom-developer] RE: NULL_OR_ON_C_STACK macro invalid (was: noweb), Page, Bill, 2006/08/10
- [Axiom-developer] RE: NULL_OR_ON_C_STACK macro invalid (was: noweb), Page, Bill, 2006/08/10
- [Axiom-developer] Re: NULL_OR_ON_C_STACK macro invalid (was: noweb), Camm Maguire, 2006/08/24
- [Axiom-developer] RE: NULL_OR_ON_C_STACK macro invalid (was: noweb), Page, Bill, 2006/08/30
- [Axiom-developer] Re: NULL_OR_ON_C_STACK macro invalid (was: noweb), Camm Maguire, 2006/08/11
- Re: [Axiom-developer] Re: NULL_OR_ON_C_STACK macro invalid (was: noweb), Vanuxem Grégory, 2006/08/11