Kostik Belousov <kostikbel_at_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?Received on Mon Mar 16 2009 - 20:24:45 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:44 UTC