[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] OpenBSD: huge allocation?
From: |
Magnus Henoch |
Subject: |
[Gcl-devel] OpenBSD: huge allocation? |
Date: |
Fri, 26 Mar 2004 17:22:26 +0100 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) |
Further debugging GCL on OpenBSD, specifically o/alloc.c, I activated
the debug-outputting version of sbrk (and activated baby_malloc, since
printf and friends use malloc), and got the following output from
raw_pre_gcl:
GCL (GNU Common Lisp) April 1994 131072 pages
{sbrk(0)->[0x3c17c2fc]core_end=0x0,sbrk(0)=0x3c17c2fc}
{sbrk(3332)->[0x3c17c2fc]core_end=0x0,sbrk(0)=0x3c17d000}
{sbrk(0)->[0x3c17d000]core_end=0x0,sbrk(0)=0x3c17d000}
{sbrk(0)->[0x3c17d000]core_end=0x3c17d000,sbrk(0)=0x3c17d000}
{sbrk(85893120)->[0xffffffff]core_end=0x3c17d000,sbrk(0)=0x3c17d000}
Unrecoverable error: Can't allocate. Good-bye!.
Abort trap (core dumped)
Backtrace:
(gdb) bt
#0 0xbe51f3d in _thread_sys_kill ()
#1 0xbe7d925 in abort ()
#2 0x1c002d91 in error (s=0x3c00a5c7 "Can't allocate. Good-bye!")
at main.c:369
#3 0x1c0399d7 in alloc_page (n=20970) at alloc.c:150
#4 0x1c03b53c in gcl_init_alloc () at alloc.c:778
#5 0x1c002dd5 in initlisp () at main.c:384
#6 0x1c002b8f in main (argc=4, argv=0xcfbf09e4, envp=0xcfbf09f8)
at main.c:314
#7 0x1c002461 in ___start ()
#8 0x1c0023d7 in __start ()
#9 0xcfbf0b58 in ?? ()
(gdb) f 4
#4 0x1c03b53c in gcl_init_alloc () at alloc.c:778
778 alloc_page(-(holepage + nrbpage));
(gdb) p holepage
$1 = 15728
(gdb) p nrbpage
No symbol "nrbpage" in current context.
(gdb) q
[why is nrbpage not available?]
$ ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) 65536
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 78874
max memory size (kbytes, -m) 235488
open files (-n) 64
pipe size (512 bytes, -p) 1
stack size (kbytes, -s) 4096
cpu time (seconds, -t) unlimited
max user processes (-u) 64
virtual memory (kbytes, -v) 69632
This last sbrk call, trying to get 85 megabytes of memory - is that
reasonable?
I su'd to root, did "ulimit -d 100000", and this happened:
GCL (GNU Common Lisp) April 1994 131072 pages
{sbrk(0)->[0x3c17c2fc]core_end=0x0,sbrk(0)=0x3c17c2fc}
{sbrk(3332)->[0x3c17c2fc]core_end=0x0,sbrk(0)=0x3c17d000}
{sbrk(0)->[0x3c17d000]core_end=0x0,sbrk(0)=0x3c17d000}
{sbrk(0)->[0x3c17d000]core_end=0x3c17d000,sbrk(0)=0x3c17d000}
{sbrk(85893120)->[0x3c17d000]core_end=0x3c17d000,sbrk(0)=0x41367000}Building
symbol table for ./raw_pre_gcl ..
loading ./../lsp/gcl_export.lsp
loading ./../lsp/gcl_defmacro.lsp
loading ./../lsp/gcl_evalmacros.lsp
loading ./../lsp/gcl_top.lsp
loading ./../lsp/gcl_module.lsp
loading ./../lsp/gcl_autoload.lsp
>
This is progress, sort of. I'll look more at this later.
Regards,
Magnus
- [Gcl-devel] OpenBSD: huge allocation?,
Magnus Henoch <=