lang/sbcl consumes all available memory and dies
kostikbel at gmail.com
Mon Mar 16 12:45:50 PDT 2009
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,
> 18.104.22.168. 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 ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090316/7d3399ef/attachment.pgp
More information about the freebsd-current