From owner-freebsd-stable Sat Feb 3 14:50:46 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA09159 for stable-outgoing; Sat, 3 Feb 1996 14:50:46 -0800 (PST) Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA09153 for ; Sat, 3 Feb 1996 14:50:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by Root.COM (8.6.12/8.6.5) with SMTP id OAA11046; Sat, 3 Feb 1996 14:50:47 -0800 Message-Id: <199602032250.OAA11046@Root.COM> X-Authentication-Warning: implode.Root.COM: Host localhost didn't use HELO protocol To: Douglas Thomas Crosher cc: freebsd-stable@freebsd.org Subject: Re: Help: trap fault when swapping In-reply-to: Your message of "Sun, 04 Feb 1996 07:43:43 +1100." <199602032043.HAA07606@scrooge.ee.swin.oz.au> From: David Greenman Reply-To: davidg@Root.COM Date: Sat, 03 Feb 1996 14:50:46 -0800 Sender: owner-stable@freebsd.org Precedence: bulk > Every time I try running large lisp programs on my rather >memory limit PC the freebsd kernels give me trouble. I not sure if it ... >Fatal trap 12: page fault while in kernel mode >fault virtual address = 0xdeadc10a ... >stopped at _sysctl_doproc + 0x64: cmp $0x1, 0x2c(%ebx) This is actually a difficult bug to fix. It's caused by the sysctl system- call blocking while it's copying out process information; such is the case when you run ps(1) or 'top' while the system is paging heavily. The current process that it's copying out information for has exited and the p_next pointer has become invalid because the proc data structure was freed. Whenever a process blocks, the state of the linked processes in the process list can and often will change - you can't assume anything about it after the process wakes up again. One way to fix this would be to make sure that the system call is atomic and doesn't block. This requires faulting and locking the process' pages into memory before traversing the proc list. The problem with this is that the memory required to copy out the information for all of the processes in the system might be quite large (perhaps exceeding the amount of available memory!). There are other possible solutions...I'll have to think about this problem more and discuss it with some other people. >I did a 'show map' and got: The "show map" command is broken in DDB, and in any case is not relavent to this problem. -DG David Greenman Core Team/Principal Architect, The FreeBSD Project