Greetings! "Page, Bill" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > Sent: Tuesday, August 08, 2006 6:43 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; axiom-developer@nongnu.org > 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 "[EMAIL PROTECTED]@#(`cat ../majvers`.`cat ../minvers`) `date`#1" \ > -e "[EMAIL PROTECTED]@#`cat ../minvers | cut -f2 -d.`#1" \ > -e "[EMAIL PROTECTED]@#`cat ../minvers | cut -f1 -d.`#1" \ > -e "[EMAIL PROTECTED]@#`cat ../majvers`#1" \ > -e "[EMAIL PROTECTED]@#\"gcc -c -Wall -DVOL=volatile -fsigned-char > -pipe > \"#1" \ > -e "[EMAIL PROTECTED]@#\"gcc -o \"#1" \ > -e "[EMAIL PROTECTED]@#\" -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 "[EMAIL PROTECTED]@#\"-O3 -fomit-frame-pointer\"#1" \ > -e "[EMAIL PROTECTED]@#\"-O\"#1" \ > -e "[EMAIL PROTECTED]@#\"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 [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer