Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Mar 2009 00:24:03 +0300
From:      Anonymous <swell.k@gmail.com>
To:        Kostik Belousov <kostikbel@gmail.com>
Cc:        freebsd-current@freebsd.org
Subject:   Re: lang/sbcl consumes all available memory and dies
Message-ID:  <86ljr5p3f0.fsf@gmail.com>
References:  <864oxtuzct.fsf@gmail.com> <20090316194541.GO41617@deviant.kiev.zoral.com.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
Kostik Belousov <kostikbel@gmail.com> writes:

> On Mon, Mar 16, 2009 at 08:55:14PM +0300, Anonymous wrote:
>> I noticed that after commit r189771 (ELF: .note.ABI-tag) sbcl
>> starts to eat all memory until it dies from bus error never reaching
>> REPL. The process is unkillable, too.
>> 
>>   $ sbcl
>>   This is SBCL 1.0.25, an implementation of ANSI Common Lisp.
>>   More information about SBCL is available at <http://www.sbcl.org/>.
>> 
>>   SBCL is free software, provided as is, with absolutely no warranty.
>>   It is mostly in the public domain; some portions are provided under
>>   BSD-style licenses.  See the CREDITS and COPYING files in the
>>   distribution for more information.
>>   load: 0.06  cmd: sbcl 1926 [running] 0.01u 0.44s 3% 189432k
>>   load: 0.06  cmd: sbcl 1926 [tx->tx_quiesce_done_cv)] 0.01u 0.72s 5% 367124k
>>   load: 0.78  cmd: sbcl 1926 [running] 0.01u 2.91s 14% 1763028k
>>   load: 0.72  cmd: sbcl 1926 [tx->tx_quiesce_done_cv)] 0.01u 3.65s 14% 2237272k
>>   load: 0.74  cmd: sbcl 1926 [*vm page queue mutex] 0.01u 5.78s 9% 3482892k
>>   zsh: bus error (core dumped)  sbcl
>> 
>> This is amd64, r189876M, zfs, 4g mem, 4g swap, sbcl 1.0.17, sbcl-1.0.25,
>> 1.0.26.3. I can reproduce it under qemu with clean environment as well.
>> 
>> Can somebody confirm it on i386? Just run `sbcl' and exit from REPL by
>> either `^D' or `(quit)'.
>> 
>> The workaround is to reverse-apply diff from r189771.
>
> I think the D-state is due to quite large vm address space of the lisp,
> that takes a long time to dump.
> For the start, can you confirm that setting sysctl
> machdep.prot_fault_translation to 2 solves your problem ?

Yep, machdep.prot_fault_translation=2 solves it on my main amd64 box and
in qemu-amd64. Anything else?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86ljr5p3f0.fsf>