Date: Mon, 16 Mar 2009 23:52:05 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Anonymous <swell.k@gmail.com> Cc: freebsd-current@freebsd.org, dchagin@freebsd.org Subject: Re: lang/sbcl consumes all available memory and dies Message-ID: <20090316215205.GS41617@deviant.kiev.zoral.com.ua> In-Reply-To: <86ljr5p3f0.fsf@gmail.com> References: <864oxtuzct.fsf@gmail.com> <20090316194541.GO41617@deviant.kiev.zoral.com.ua> <86ljr5p3f0.fsf@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--6qwK1L4ASmC+eXbp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 17, 2009 at 12:24:03AM +0300, Anonymous wrote: > Kostik Belousov <kostikbel@gmail.com> writes: >=20 > > 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. > >>=20 > >> $ sbcl > >> This is SBCL 1.0.25, an implementation of ANSI Common Lisp. > >> More information about SBCL is available at <http://www.sbcl.org/>. > >>=20 > >> 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% 348= 2892k > >> zsh: bus error (core dumped) sbcl > >>=20 > >> This is amd64, r189876M, zfs, 4g mem, 4g swap, sbcl 1.0.17, sbcl-1.0.2= 5, > >> 1.0.26.3. I can reproduce it under qemu with clean environment as well. > >>=20 > >> Can somebody confirm it on i386? Just run `sbcl' and exit from REPL by > >> either `^D' or `(quit)'. > >>=20 > >> 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 ? >=20 > Yep, machdep.prot_fault_translation=3D2 solves it on my main amd64 box and > in qemu-amd64. Anything else? Please, try this patch. diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c index f2bdcf5..5604ea5 100644 --- a/sys/kern/imgact_elf.c +++ b/sys/kern/imgact_elf.c @@ -1330,14 +1330,14 @@ __elfN(check_note)(struct image_params *imgp, Elf_B= randnote *checknote, int32_t *osrel) { const Elf_Note *note, *note_end; - const Elf32_Phdr *phdr, *pnote; - const Elf32_Ehdr *hdr; + const Elf_Phdr *phdr, *pnote; + const Elf_Ehdr *hdr; const char *note_name; int i; =20 pnote =3D NULL; - hdr =3D (const Elf32_Ehdr *)imgp->image_header; - phdr =3D (const Elf32_Phdr *)(imgp->image_header + hdr->e_phoff); + hdr =3D (const Elf_Ehdr *)imgp->image_header; + phdr =3D (const Elf_Phdr *)(imgp->image_header + hdr->e_phoff); =20 for (i =3D 0; i < hdr->e_phnum; i++) { if (phdr[i].p_type =3D=3D PT_NOTE) { --6qwK1L4ASmC+eXbp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkm+ygQACgkQC3+MBN1Mb4i+/ACgyMTIiyaH2PlBcKIUhGb3208r yz4AniZaGBjCwxhQXtaN4kmzHzjVqhJL =GqwX -----END PGP SIGNATURE----- --6qwK1L4ASmC+eXbp--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090316215205.GS41617>