gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] OpenBSD: huge allocation?


From: Camm Maguire
Subject: Re: [Gcl-devel] OpenBSD: huge allocation?
Date: 26 Mar 2004 12:12:17 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!  First, my Debian ulimit -a:

ulimit -a
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) 4091
virtual memory        (kbytes, -v) unlimited

Magnus Henoch <address@hidden> writes:

> 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

You need baby malloc due to the printf's called by debugging sbrk?
Please let me know if for some reason you need baby_malloc still even
when debugging versions are not used.

> 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?]
> 

nrbpage is a C define to tm_table[t_relocatable].tm_maxpage.  

> $ 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 think so.  The default hole size is 1/10 of MAXPAGES, the latter of
which amounts to 512Mb.

> 
> 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.
> 

Indeed!  Please keep us posted!  I'd wager that you're ready to go if
you can unlimit the data seg size.

Take care,

> Regards,
> Magnus
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

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