From owner-freebsd-current Sat Jul 11 19:07:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA00628 for freebsd-current-outgoing; Sat, 11 Jul 1998 19:07:14 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp01.primenet.com (root@smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA00576 for ; Sat, 11 Jul 1998 19:07:06 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id RAA10910; Sat, 11 Jul 1998 17:53:05 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpd010889; Sat Jul 11 17:52:58 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id RAA15975; Sat, 11 Jul 1998 17:52:51 -0700 (MST) From: Terry Lambert Message-Id: <199807120052.RAA15975@usr08.primenet.com> Subject: Re: Arrgh ! resubscribing again again again.... To: dg@root.com Date: Sun, 12 Jul 1998 00:52:51 +0000 (GMT) Cc: tlambert@primenet.com, current@FreeBSD.ORG In-Reply-To: <199807111110.EAA15688@implode.root.com> from "David Greenman" at Jul 11, 98 04:10:56 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >When no backing pages exist (becaues you've used them all up and are > >out of swap space), the process requesting the page as a result of > >the copy on write fault can not have its request satisfied. > > > >The result of an unsatified fault request is a SIGSEGV, or signal 11; > > Wrong. The result of running out of swap space is a SIGKILL, or signal 9. > The bug that people are refering to seems to have been introduced around the > time that John was messing with the VM map code, but might predate that to > when he was messing with some of the swap pager algorithms. Hmmm. I was able to cause the problem (with SIGSEGV) by mapping a large shared memory segment, and then traversing the pages to dirty them (one byte per page). I see in the VM code where a SIGKILL could result, but it seems to me that the page table entry exists, it just doesn't have pages to back it, and when the page to back the entry fails allocation, you get SIGSEGV, since it isn't mapped when you do the reference. Am I reading this code wrong? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message