From: Andrej G. <gr...@pa...> - 2005-12-23 15:11:48
|
Hello *, I've just got access to an AMD Opteron computer with 4Gb running SUSE-9.3 (with both 64-bit and 32-bit libraries). Naturally, it would be nice to use all this memory to do symbolic computations :-) So, I downloaded sbcl-0.9.7-x86-64-linux-binary.tar.bz2 and installed it in my home directory. It seems to work (with the appropriate SBCL_HOME set). Then I downloaded maxima-5.9.2.tar.gz configured it to use sbck, and started make. After some time (with only style warnings from sbcl), I got: fatal error encountered in SBCL pid 5108(tid 46912503122688): GC invariant lost, file "gc-common.c", line 137 The system is too badly corrupted or confused to continue at the Lisp level. If the system had been compiled with the SB-LDB feature, we'd drop into the LDB low-level debugger now. But there's no LDB in this build, so we can't really do anything but just exit, sorry. I never had problems compiling maxima with sbcl on 32-bit Linux systems. What should I do? Can compiling sbcl from sources help? Merry Christmas to all developers, Andrey |
From: Juho S. <js...@ik...> - 2005-12-23 18:24:44
|
On Fri, Dec 23, 2005 at 04:11:42PM +0100, Andrej Grozin wrote: > So, I downloaded > sbcl-0.9.7-x86-64-linux-binary.tar.bz2 > and installed it in my home directory. It seems to work (with the > appropriate SBCL_HOME set). Then I downloaded > maxima-5.9.2.tar.gz > configured it to use sbck, and started make. After some time (with only > style warnings from sbcl), I got: > > fatal error encountered in SBCL pid 5108(tid 46912503122688): > GC invariant lost, file "gc-common.c", line 137 Works for me (with several x86-64 snapshots between 0.9.7 and HEAD, haven't tested the sf binary). Does this happen repeatably on every build, every now and then, or was it a unique occurence? Do you have any strange stuff in your .sbclrc? -- Juho Snellman |
From: Andrej G. <gr...@pa...> - 2005-12-24 10:11:57
|
On Fri, 23 Dec 2005, Juho Snellman wrote: > On Fri, Dec 23, 2005 at 04:11:42PM +0100, Andrej Grozin wrote: > > So, I downloaded > > sbcl-0.9.7-x86-64-linux-binary.tar.bz2 > > and installed it in my home directory. It seems to work (with the > > appropriate SBCL_HOME set). Then I downloaded > > maxima-5.9.2.tar.gz > > configured it to use sbck, and started make. After some time (with only > > style warnings from sbcl), I got: > > > > fatal error encountered in SBCL pid 5108(tid 46912503122688): > > GC invariant lost, file "gc-common.c", line 137 > > Works for me (with several x86-64 snapshots between 0.9.7 and HEAD, > haven't tested the sf binary). Does this happen repeatably on every > build, every now and then, or was it a unique occurence? Do you have > any strange stuff in your .sbclrc? This happens every time I try make, in one and the same place. Here is a larger piece of the log: ; in: DEFUN COMPILED-FILE-P ; (DEFUN MAKE::COMPILED-FILE-P (MAKE::FILE-NAME) ; "Return T if the FILE-NAME is a filename designator for a valid compiled. ; Signal an error when it is not a filename designator. ; Return NIL when the file does not exist, or is not readable, ; or does not contain valid compiled code." ; T) ; --> PROGN EVAL-WHEN SB-IMPL::%DEFUN SB-INT:NAMED-LAMBDA ; ==> ; #'(SB-INT:NAMED-LAMBDA MAKE::COMPILED-FILE-P ; (MAKE::FILE-NAME) ; (BLOCK MAKE::COMPILED-FILE-P T)) ; ; caught STYLE-WARNING: ; The variable FILE-NAME is defined but never used. ; ; compilation unit finished ; caught 1 STYLE-WARNING condition fatal error encountered in SBCL pid 10490(tid 46912503122688): GC invariant lost, file "gc-common.c", line 137 The system is too badly corrupted or confused to continue at the Lisp level. If the system had been compiled with the SB-LDB feature, we'd drop into the LDB low-level debugger now. But there's no LDB in this build, so we can't really do anything but just exit, sorry. I don't have .sbclrc Andrej |
From: Andrej G. <gr...@pa...> - 2005-12-24 14:09:43
|
I've tried to build sbcl-0.9.7 from sources, using the binary sbcl-0.9.7 for x86_64 (from sourceforge). Running sh make.sh ends with: ; compiling file "/fs1/grozin/soft/sbcl-0.9.7/src/code/show.lisp" (written 14 JUL 2005 06:30:38 PM): ; compiling (IN-PACKAGE "SB!INT") ; compiling (DEFUN CANNOT-/SHOW ...) ; file: /fs1/grozin/soft/sbcl-0.9.7/src/code/show.lisp ; in: DEFUN CANNOT-/SHOW ; (VALUES) ; ; note: deleting unreachable code ; compiling (DEFMACRO /SHOW ...) ; compiling (DEFMACRO /NOSHOW ...) ; compiling (DEFMACRO /XHOW ...) ; compiling (DEFMACRO /NOXHOW ...) ; compiling (DEFMACRO /SHOW0 ...) ; compiling (DEFMACRO /NOSHOW0 ...)fatal error encountered in SBCL pid 12255(tid 46912503122688): GC invariant lost, file "gc-common.c", line 190 The system is too badly corrupted or confused to continue at the Lisp level. If the system had been compiled with the SB-LDB feature, we'd drop into the LDB low-level debugger now. But there's no LDB in this build, so we can't really do anything but just exit, sorry. So, it seems that this binary sbcl is unusable on this system (SUSE-9.3 on AMD Opteron). I'll try now to install a 32-bit binary sbcl, and use it to bootstrap the 64-bit version. Andrej |
From: Andrej G. <gr...@pa...> - 2005-12-24 14:42:33
|
More news. I've installed (in my home directory) the 32-bit binary of sbcl-0.9.7, and it seems to work. I've tried to compile the source of sbcl-0.9.7 with it (uname -m gives x86_64, so, make.sh is trying co build a 64-bit sbcl, right?) After quite some time and a lot of stuff compiled, I got ; compiling file "/fs1/grozin/soft/sbcl-0.9.7/src/pcl/macros.lisp" (written 14 JUL 2005 09:45:42 PM): ; compiling (IN-PACKAGE "SB-PCL") ; compiling (/SHOW "starting pcl/macros.lisp") ; compiling (DECLAIM (DECLARATION %METHOD-NAME ...)) ; compiling (/SHOW "done with DECLAIM DECLARATION") ; compiling (DEFUN GET-DECLARATION ...) ; compiling (/SHOW "pcl/macros.lisp 85") ; compiling (DEFMACRO DOPLIST ...) ; compiling (/SHOW "pcl/macros.lisp 101") ; compiling (DEFMACRO DOLIST-CAREFULLY ...) ; compiling (/SHOW "pcl/macros.lisp 119") ; compiling (DEFVAR *FIND-CLASS* ...) ; compiling (DEFMACRO FIND-CLASS-CELL-CLASS ...) ; compiling (DEFMACRO FIND-CLASS-CELL-PREDICATE ...) ; compiling (DEFMACRO MAKE-FIND-CLASS-CELL ...) ; compiling (DEFUN FIND-CLASS-CELL ...) ; compiling (/SHOW "pcl/macros.lisp 157") ; compiling (DEFVAR *CREATE-CLASSES-FROM-INTERNAL-STRUCTURE-DEFINITIONS-P* ...) ; compiling (DEFUN FIND-CLASS-FROM-CELL ...)fatal error encountered in SBCL pid 13778: no pointer at 0 in hash table The system is too badly corrupted or confused to continue at the Lisp level. If the system had been compiled with the SB-LDB feature, we'd drop into the LDB low-level debugger now. But there's no LDB in this build, so we can't really do anything but just exit, sorry. I am running out of ideas. I can try to build clisp and use it to compile sbcl... Andrej |
From: Brian M. <br...@ma...> - 2005-12-24 15:13:07
|
On Dec 24, 2005, at 8:42 AM, Andrej Grozin wrote: > More news. I've installed (in my home directory) the 32-bit binary of > sbcl-0.9.7, and it seems to work. I've tried to compile the source of > sbcl-0.9.7 with it (uname -m gives x86_64, so, make.sh is trying co > build > a 64-bit sbcl, right?) After quite some time and a lot of stuff > compiled, > I got <snip> What is your kernel version? What is your glibc version? -- Brian Mastenbrook br...@ma... http://brian.mastenbrook.net/ |
From: Andrej G. <gr...@pa...> - 2005-12-24 15:25:39
|
On Sat, 24 Dec 2005, Brian Mastenbrook wrote: > What is your kernel version? What is your glibc version? kernel-smp-2.6.11.4-21.9 glibc-2.3.4-23.4 /etc/SuSE-release says it's SuSE Linux 9.3 (x86-64) (I have no root acess to this computer) Andrej |
From: Juho S. <js...@ik...> - 2005-12-25 06:29:33
|
On Sat, Dec 24, 2005 at 04:25:30PM +0100, Andrej Grozin wrote: > On Sat, 24 Dec 2005, Brian Mastenbrook wrote: > > What is your kernel version? What is your glibc version? > kernel-smp-2.6.11.4-21.9 > glibc-2.3.4-23.4 > > /etc/SuSE-release says it's SuSE Linux 9.3 (x86-64) > (I have no root acess to this computer) Suse 9.3 is believed to have a broken gcc which miscompiles SBCL. The failure to rebuild SBCL from source on this computer is therefore no wonder, especially as the crashes were in the newly-compiled SBCL, not the SBCL being used as host compiler. It's more worrying that the 0.9.7 binary from sf.net is gc_asserting with Maxima. If you're up for one more experiment, could you try building Maxima with the x86-64 0.9.6 binary from sourceforge? Merry christmas, -- Juho Snellman |
From: Andrej G. <gr...@pa...> - 2005-12-25 13:28:55
|
On Sun, 25 Dec 2005, Juho Snellman wrote: > Suse 9.3 is believed to have a broken gcc which miscompiles SBCL. The > failure to rebuild SBCL from source on this computer is therefore no > wonder, especially as the crashes were in the newly-compiled SBCL, not > the SBCL being used as host compiler. > > It's more worrying that the 0.9.7 binary from sf.net is gc_asserting > with Maxima. If you're up for one more experiment, could you try > building Maxima with the x86-64 0.9.6 binary from sourceforge? Thanks for your suggestion. I installed the x86-64 0.9.6 binary and tried to compile maxima. The result is the same: ; compilation unit finished ; caught 2 STYLE-WARNING conditions fatal error encountered in SBCL pid 6779(tid 46912503122688): GC invariant lost, file "gc-common.c", line 137 The system is too badly corrupted or confused to continue at the Lisp level. If the system had been compiled with the SB-LDB feature, we'd drop into the LDB low-level debugger now. But there's no LDB in this build, so we can't really do anything but just exit, sorry. OK, I think I'll wait until local sysadmins install SUSE-10.0. It has a very new gcc, 4.0.2 I think, is this OK to compile sbcl? The kernel is, I think, 2.6.13, and glibc is 2.3.5 (though I am not quite sure). By the way, one more question. Suppose, I'll finally succeed in building maxima with a 64-bit sbcl. Do I have to do something special in order to use several gigabytes of memory in maxima? Or is it automatic? Best wishes to all of you, Andrej |
From: Brian M. <br...@ma...> - 2005-12-24 15:31:28
|
On Dec 24, 2005, at 9:25 AM, Andrej Grozin wrote: > On Sat, 24 Dec 2005, Brian Mastenbrook wrote: >> What is your kernel version? What is your glibc version? > kernel-smp-2.6.11.4-21.9 > glibc-2.3.4-23.4 > > /etc/SuSE-release says it's SuSE Linux 9.3 (x86-64) > (I have no root acess to this computer) > > Andrej Hm. This doesn't resemble the expected failure on 2.6.11, but nevertheless 2.6.11 on x86-64 has a known bug which affects SBCL. Can you upgrade to 2.6.12 or later? -- Brian Mastenbrook br...@ma... http://brian.mastenbrook.net/ |
From: Andrej G. <gr...@pa...> - 2005-12-24 18:11:15
|
On Sat, 24 Dec 2005, Brian Mastenbrook wrote: > Can you upgrade to 2.6.12 or later? I am not root on this computer. Local sysadmins are considering the possibility to install SUSE-10.0 instead 0f 9.3 (which was preinstalled). I suppose, 10.0 has a newer kernel; but this software upgrade will not happen immediately. Thanks for your response, Andrej |
From: Juho S. <js...@ik...> - 2005-12-25 18:16:08
|
On Sun, Dec 25, 2005 at 02:28:48PM +0100, Andrej Grozin wrote: > On Sun, 25 Dec 2005, Juho Snellman wrote: > > It's more worrying that the 0.9.7 binary from sf.net is gc_asserting > > with Maxima. If you're up for one more experiment, could you try > > building Maxima with the x86-64 0.9.6 binary from sourceforge? > Thanks for your suggestion. I installed the x86-64 0.9.6 binary and tried > to compile maxima. The result is the same: Ok, thanks. > OK, I think I'll wait until local sysadmins install SUSE-10.0. It has a > very new gcc, 4.0.2 I think, is this OK to compile sbcl? The kernel is, I > think, 2.6.13, and glibc is 2.3.5 (though I am not quite sure). Sounds fine. > By the way, one more question. Suppose, I'll finally succeed in building > maxima with a 64-bit sbcl. Do I have to do something special in order to > use several gigabytes of memory in maxima? Or is it automatic? You can use up to 8GB by default. More than that, and you'll need to edit some parameters in the source code and recompile. -- Juho Snellman |
From: Andrej G. <gr...@pa...> - 2005-12-25 18:19:40
|
On Sun, 25 Dec 2005, Juho Snellman wrote: > > By the way, one more question. Suppose, I'll finally succeed in building > > maxima with a 64-bit sbcl. Do I have to do something special in order to > > use several gigabytes of memory in maxima? Or is it automatic? > > You can use up to 8GB by default. More than that, and you'll need to > edit some parameters in the source code and recompile. This computer has 4GB. So, I just start maxima, and it will use up to 4GB? Andrej |
From: Brian M. <br...@ma...> - 2005-12-25 19:13:34
|
On 12/25/05 12:19 PM, "Andrej Grozin" <gr...@pa...> wrote: > On Sun, 25 Dec 2005, Juho Snellman wrote: >>> By the way, one more question. Suppose, I'll finally succeed in building >>> maxima with a 64-bit sbcl. Do I have to do something special in order to >>> use several gigabytes of memory in maxima? Or is it automatic? >> >> You can use up to 8GB by default. More than that, and you'll need to >> edit some parameters in the source code and recompile. > This computer has 4GB. So, I just start maxima, and it will use up to 4GB? Hopefully not until you actually do something to cause it to use that much memory :-) Seriously, yes, you can use up to 8GB of real memory for maxima, since maxima doesn't do anything particular related to memory allocation (more or less the same as any other Common Lisp program). -- Brian Mastenbrook br...@ma... http://brian.mastenbrook.net/ |
From: Andrej G. <gr...@pa...> - 2006-01-16 12:10:01
|
Hello *, I am still trying to compile maxima with the 64-bit sbcl on an AMD Opteron computer with 4Gb. Yesterday, SUSE-10.0 was installed on it: kernel-smp-2.6.13-15 glibc-2.3.5-40 gcc-4.0.2_20050901-3 I installed sbcl-0.9.8-x86-64-linux-binary.tar.bz2 from sf.net in my home directory. When making maxima-5.9.2, I get (in 100% of cases, in one and the same place) ; caught STYLE-WARNING: ; These functions are undefined: ; CREATE-COMPONENT-PATHNAMES EXPAND-COMPONENT-COMPONENTS LINK-COMPONENT-DEPENDS-ON TOPOLOGICAL-SORT ; ; compilation unit finished ; caught 5 STYLE-WARNING conditions fatal error encountered in SBCL pid 11235(tid 46912503143168): GC invariant lost, file "gc-common.c", line 137 The system is too badly corrupted or confused to continue at the Lisp level. If the system had been compiled with the SB-LDB feature, we'd drop into the LDB low-level debugger now. But there's no LDB in this build, so we can't really do anything but just exit, sorry. Any further ideas? Andrej |
From: Juho S. <js...@ik...> - 2006-01-19 05:01:15
|
On Mon, Jan 16, 2006 at 01:09:45PM +0100, Andrej Grozin wrote: > Hello *, > > I am still trying to compile maxima with the 64-bit sbcl on an AMD Opteron > computer with 4Gb. Yesterday, SUSE-10.0 was installed on it: [...] > GC invariant lost, file "gc-common.c", line 137 [...] > Any further ideas? Not many, though a similar problem was just reported on sbcl-help. <http://cs.helsinki.fi/u/jesnellm/tmp/sbcl-0.9.8.44.tar.bz2> contains a couple of SBCL x86-64 binaries built with different options that you could test, but this is pretty much a shot in the dark. If neither of those binaries works, making any progress with this would probably require getting access to one of the machines that exhibit this error for some hands-on debugging. -- Juho Snellman |
From: Juho S. <js...@ik...> - 2006-01-20 08:37:43
|
On Thu, Jan 19, 2006 at 07:01:00AM +0200, Juho Snellman wrote: [...] >>> GC invariant lost, file "gc-common.c", line 137 [...] > If neither of those binaries works, making any progress with this > would probably require getting access to one of the machines that > exhibit this error for some hands-on debugging. Well, that was fun. The SuSE glibc takes advantage of some x86-64 ABI guarantees with regards to the state of the direction flag, which the vanilla glibc doesn't. Since we weren't clearing the direction flag on every transition from Lisp to C, memcpy() would sometimes end up copying the wrong things into the wrong place, causing massive memory corruption. This should be fixed in 0.9.8.47. (A binary is available at <http://cs.helsinki.fi/u/jesnellm/tmp/sbcl-0.9.8.47.tar.bz2> for a few days, if you want to test this before 0.9.9 is released). -- Juho Snellman |
From: Andrej G. <gr...@pa...> - 2006-01-20 10:10:12
|
On Fri, 20 Jan 2006, Juho Snellman wrote: > >>> GC invariant lost, file "gc-common.c", line 137 > > Well, that was fun. > > The SuSE glibc takes advantage of some x86-64 ABI guarantees with > regards to the state of the direction flag, which the vanilla glibc > doesn't. Since we weren't clearing the direction flag on every > transition from Lisp to C, memcpy() would sometimes end up copying the > wrong things into the wrong place, causing massive memory corruption. > > This should be fixed in 0.9.8.47. (A binary is available at > <http://cs.helsinki.fi/u/jesnellm/tmp/sbcl-0.9.8.47.tar.bz2> for a few > days, if you want to test this before 0.9.9 is released). Many thanks! sbcl-0.9.8.47 does compile maxima, and maxima works (have not yet run the full testsuite, will do so soon). Andrej |
From: Christophe R. <cs...@ca...> - 2006-01-20 10:46:17
|
Juho Snellman <js...@ik...> writes: > The SuSE glibc takes advantage of some x86-64 ABI guarantees with > regards to the state of the direction flag, which the vanilla glibc > doesn't. Since we weren't clearing the direction flag on every > transition from Lisp to C, memcpy() would sometimes end up copying the > wrong things into the wrong place, causing massive memory corruption. According to at least one draft copy of the System V ABI for i386 (which I found at <http://www.caldera.com/developers/devspecs/abi386-4.pdf>) the requirement on the direction flag is also there for the x86. We are respecting this on SunOS and Win32 at the moment, but not on Linux (or *BSD; I don't know whether the *BSDs think they have the System V ABI, or if they don't whether the direction flag is critical there). The current implementation I think has the direction flag cleared eagerly on SunOS and lazily (as in the x86-64 patch) on Win32; I would propose making the lazy clearing unconditional on the x86. Does that make sense? Cheers, Christophe |
From: Juho S. <js...@ik...> - 2006-01-20 12:04:30
|
On Fri, Jan 20, 2006 at 10:45:53AM +0000, Christophe Rhodes wrote: > The current implementation I think has the direction flag cleared > eagerly on SunOS and lazily (as in the x86-64 patch) on Win32; I would > propose making the lazy clearing unconditional on the x86. Sounds good. Thinking a bit more about this, the win32 and x86-64 implementations should be augmented with clearing the flag on return from a callback. There should probably also be a CLD the end of call_into_lisp (missing for win32). -- Juho Snellman |