Steel Bank Common Lisp

"Peter Hertmuller" <phertmuller@...> writes:

> I'm having problems running sbcl. I'll try to be as concise as possible:
> 
> I start SBCL (via SLIME in a terminal), start my program, and after
> sometime, SBCL crashes, with a message like this:
> 
> Argh! gc_find_free_space failed (first_page), nbytes=8.

This means that you've run out of memory (a maximum of 512MB can be
allocated on Linux/x86 for and sbcl compiled with the default
settings).

>     Gen Boxed Unboxed LB   LUB  !move  Alloc  Waste   Trig    WP  GCs Mem-age
>    0: 128844     1    27     0    13 527686944 172768  2050840    0   1  0.0000

And this says that practically all of the memory was used by newly
allocated small objects. Which really shouldn't be happening: while
these objects are being allocated, garbage collections should be
triggered, which move some of them from the 0th generation to older
ones.

Is your application maybe disabling the GC or alternately disabling
interrupts?

-- 
Juho Snellman

> >     Gen Boxed Unboxed LB   LUB  !move  Alloc  Waste   Trig    WP  GCs
> Mem-age
> >    0: 128844     1    27     0    13 527686944 172768  2050840    0
> 1  0.0000
>
> And this says that practically all of the memory was used by newly
> allocated small objects. Which really shouldn't be happening: while
> these objects are being allocated, garbage collections should be
> triggered, which move some of them from the 0th generation to older
> ones.




Is your application maybe disabling the GC or alternately disabling
> interrupts?


No, the application does not disable the GC or interrupts. I've been trying
to force the call to the gc by means of (sb-ext:gc). It didn't work.

I've downloaded the source code from CVS, and I've tried to increase the
dynamic memory space changing the parms.lisp file under /src/compiler/x86/
folder (I've followed the recomedations made in an email sometime ago for an
X86-64 machine). My machine has 2GB of RAM, so I've increased the memory
figures up to 1GB (changing the dynamic-space-end from 512MB (x29000000) up
to 1GB (x49000000), considering that the dynamic-space-starts at x09000000.
This didn't work as well. I've got an error when the compiler fires the
make-target-2.sh. Appears the error:

 //doing warm init

mmap: wanted 1073741824 bytes at 0x9000000, actually mapped at 0x40182000

ensure_space: failed to validate 1073741824 bytes at 0x09000000

(hint: Try "ulimit -a"; maybe you should increase memory limits.)

Typing "ulimit -a" appears the following information (in a Xeon machine with
2GB RAM)

core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited

The parms.lisp file is not enough documented and I'm not able to get a
successful compilation.

Do you have any ideas about what I have to do to increase the dynamic space?

Peter



--
> Juho Snellman
>
>

"Peter Hertmuller" <phertmuller@...> writes:

> > >     Gen Boxed Unboxed LB   LUB  !move  Alloc  Waste   Trig    WP  GCs
> > Mem-age
> > >    0: 128844     1    27     0    13 527686944 172768  2050840    0
> > 1  0.0000

Ok, we got another similar report with a test-case. This was
apparently a regression on x86 since 0.9.14, and should be fixed as of
0.9.14.27. Can you check that this version also fixes your program?
 
> I've downloaded the source code from CVS, and I've tried to increase the
> dynamic memory space changing the parms.lisp file under /src/compiler/x86/
> folder (I've followed the recomedations made in an email sometime ago for an
> X86-64 machine). My machine has 2GB of RAM,

The amount of physical memory you have in your computer doesn't matter,
the issue is the available address space.

> so I've increased the memory
> figures up to 1GB (changing the dynamic-space-end from 512MB (x29000000) up
> to 1GB (x49000000), considering that the dynamic-space-starts at x09000000.
> This didn't work as well. I've got an error when the compiler fires the
> make-target-2.sh. Appears the error:
> 
>  //doing warm init
> 
> mmap: wanted 1073741824 bytes at 0x9000000, actually mapped at 0x40182000
> 
> ensure_space: failed to validate 1073741824 bytes at 0x09000000

There wasn't a gigabyte of free address space available starting at
0x900000. If that happens, you need to move the start of the dynamic
space elsewhere. You might find src/runtime/trymap.c to be useful for
determining where the reserved memory areas are on your system.

-- 
Juho Snellman