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:[EMAIL PROTECTED] Sent: Tuesday, August 08, 2006 6:43 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [email protected] 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. _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
