From: Alan R. <al...@mu...> - 2005-04-07 07:14:31
|
It was set to /Developer/qt/lib. Unsetting it caused the error to go away. Why? Didn't know that SBCL's only GC was stop and copy. I have 2G on my laptop, so could probably comfortably handle 3/4G. I don't quite understand your comment about trying a malloc - not familiar with how to reason about what the settings in parms.lisp should be changed to given what I find. My naive impression is that the various space variables in parms.lisp should range from 0 to #x80000000 for 2G of address space. Is the adjustment a matter of shuffling around the various space-start and space-end to make more room for dynamic space? Thanks, Alan BTW, you can still hose sbcl quite easily. Allocating something that exceeds the dynamic space causes death on the next gc: * (setq c (make-string (expt 2 25)) b nil) [warnings removed...] * (room) Dynamic space usage is: 144,576,832 bytes. Read-only space usage is: 19,304,448 bytes. Static space usage is: 5,368,232 bytes. Control stack usage is: 1,216 bytes. Binding stack usage is: 320 bytes. Garbage collection is currently enabled. Breakdown for dynamic space: 135,272,608 bytes for 6,531 simple-character-string objects. 9,315,440 bytes for 546,533 other objects. 144,588,048 bytes for 553,064 dynamic objects (space total.) * (gc) fatal error encountered in SBCL pid 1536: GC invariant lost, file "gc-common.c", line 605 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. -Alan On Apr 6, 2005, at 7:48 PM, Brian Mastenbrook wrote: > I've seen these malloc problems before; what's your DYLD_LIBRARY_PATH? > (or any DYLD environment variable?) > > As far as address space: I've built SBCL before with up to a 1GB heap, > though it's important to note that a 1GB heap SBCL will use up to 2GB > in the middle of GC. This isn't a problem for me (precious G5) but is > a consequence of our stop-and-copy gc. > > If you want to change this, try looking at > src/compiler/ppc/parms.lisp, at the addresses that are established for > the dynamic spaces. You should be able to find spaces that allow up to > a 1GB heap; try mallocing that amount of memory from a test program > and seeing where it puts it. > > I'm reluctant to modify SBCL to always use this much heap as it will > cut down on the ability to load foreign libraries, map files, etc. > However I might increase it some if my fights with mach-o lead me to a > general solution to reserving virtual memory addresses on OS X. > > In the future emailing sbcl-devel might be a good way to get a > response; this email address is likely going away anyway at some time > in the future, though I've been somewhat lazy about migrating > everything over. > > If you're around on IRC feel free to say hi in #lisp. If not, what are > you waiting for? > > On Apr 6, 2005, at 9:42 AM, Alan Ruttenberg wrote: > >> Hi, >> >> Saw some posts irc traffic indicating you were struggling with >> building sbcl for os x. I'm trying to do the same thing and wondering >> if you had any luck. >> I'm getting "*** malloc[2292]: Deallocation of a pointer not >> malloced: 0x7800400; This could be a double free(), or free() called >> with the middle of an allocated block; Try setting environment >> variable MallocHelp to see tools to help debug" when running >> make-target-2.sh. >> >> What I'm aiming for is building an sbcl with a larger address space - >> looks like 128M is the default. I usually use openmcl, for which this >> is not a problem, but want to run some more time consuming processes >> in a faster lisp... >> >> Any help appreciated. >> >> Thanks, >> >> Alan >> >> > -- > Brian Mastenbrook > br...@ma... > http://www.iscblog.info/ > |