From owner-freebsd-current  Sat Jul 11 19:38:23 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id TAA10027
          for freebsd-current-outgoing; Sat, 11 Jul 1998 19:38:23 -0700 (PDT)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from implode.root.com (implode.root.com [198.145.90.17])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA09920
          for <current@FreeBSD.ORG>; Sat, 11 Jul 1998 19:37:44 -0700 (PDT)
          (envelope-from root@implode.root.com)
Received: from implode.root.com (localhost [127.0.0.1])
	by implode.root.com (8.8.5/8.8.5) with ESMTP id TAA29759;
	Sat, 11 Jul 1998 19:38:03 -0700 (PDT)
Message-Id: <199807120238.TAA29759@implode.root.com>
To: Terry Lambert <tlambert@primenet.com>
cc: current@FreeBSD.ORG
Subject: Re: Arrgh ! resubscribing again again again.... 
In-reply-to: Your message of "Sun, 12 Jul 1998 02:11:36 -0000."
             <199807120211.TAA29647@usr08.primenet.com> 
From: David Greenman <dg@root.com>
Reply-To: dg@root.com
Date: Sat, 11 Jul 1998 19:38:03 -0700
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>I run something else, which grabs and sbrk's back memory, sleeping 20
...
>It's not logical, given the code, but it happens.
...
>I first noticed this problem in 2.2.6-stable.

   I think it is likely that you are seeing the effects of a bug in the
program - perhaps with the usage of sbrk (specifically, "giving back" memory),
since non-careful use of brk/sbrk will interact badly with malloc which also
does this (and malloc() can be called from libc, inside innocuous functions
like printf()).
   If that isn't the cause, then it might be caused by a kernel bug in not
properly sensing that a page has been modified, discarding the contents
without writing to swap. When this occurs with stack or data/bss pages,
pointers can end up being wrong - often 0 since the kernel will fabricate a
demand zero page if there is no backing in swap, and lead to a NULL pointer
dereference. I thought we had fixed all of these type bugs in the 2.2 branch
(actually earlier in 2.1) long ago, but perhaps there is still one lurking
somewhere. I certainly have never seen this on any of the machines that I
have access to, and I have done extensive regression testing with the 2.2
branch.

-DG

David Greenman
Co-founder/Principal Architect, The FreeBSD Project

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message