gcl-devel
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]