From owner-freebsd-current  Tue Apr 22 12:44:06 1997
Return-Path: <owner-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id MAA13846
          for current-outgoing; Tue, 22 Apr 1997 12:44:06 -0700 (PDT)
Received: from critter.dk.tfs.com (phk.cybercity.dk [195.8.129.17])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA13756;
          Tue, 22 Apr 1997 12:43:43 -0700 (PDT)
Received: from critter (localhost [127.0.0.1])
	by critter.dk.tfs.com (8.8.5/8.8.5) with ESMTP id VAA03830;
	Tue, 22 Apr 1997 21:42:41 +0200 (CEST)
To: Bruce Evans <bde@zeta.org.au>
cc: ache@nagual.ru, current@freebsd.org, dyson@freebsd.org
From: Poul-Henning Kamp <phk@dk.tfs.com>
Subject: Re: Recent vfork kernel changes broke csh & tcsh! 
In-reply-to: Your message of "Wed, 23 Apr 1997 04:43:11 +1000."
             <199704221843.EAA29497@godzilla.zeta.org.au> 
Date: Tue, 22 Apr 1997 21:42:40 +0200
Message-ID: <3828.861738160@critter>
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In message <199704221843.EAA29497@godzilla.zeta.org.au>, Bruce Evans writes:
>The procfs_mem.c fix fixed the hangs on thrd_s.
>
>>Yes, it may be csh & tcsh common bug, but I can't find what clobbers
>>exactly. It finally hits process list in both csh & tcsh, but preserving
>>process list not helps.
>
>I think our non-simple malloc() behaviour triggers broken csh behaviour.

Another one bites the dust ?  :-)

>csh frees things in the parent that are allocated (only) in the child,
>but this is not guaranteed to reset the malloc state.

Uhm, either they have shared addres room, in which case it is consistent,
or they don't, in which case it doesn't matter...  There is a reentrancy
filter on malloc now that would detect such trouble.

--
Poul-Henning Kamp           | phk@FreeBSD.ORG       FreeBSD Core-team.
http://www.freebsd.org/~phk | phk@login.dknet.dk    Private mailbox.
whois: [PHK]                | phk@tfs.com           TRW Financial Systems, Inc.
Power and ignorance is a disgusting cocktail.