From owner-freebsd-hackers  Fri Nov 21 16:20:26 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id QAA27048
          for hackers-outgoing; Fri, 21 Nov 1997 16:20:26 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA27037
          for <freebsd-hackers@freebsd.org>; Fri, 21 Nov 1997 16:20:21 -0800 (PST)
          (envelope-from julian@whistle.com)
Received: (from daemon@localhost)
	by alpo.whistle.com (8.8.5/8.8.5) id QAA04819;
	Fri, 21 Nov 1997 16:15:22 -0800 (PST)
Received: from UNKNOWN(), claiming to be "current1.whistle.com"
 via SMTP by alpo.whistle.com, id smtpd004816; Fri Nov 21 16:15:18 1997
Message-ID: <34762398.1CFBAE39@whistle.com>
Date: Fri, 21 Nov 1997 16:13:12 -0800
From: Julian Elischer <julian@whistle.com>
Organization: Whistle Communications
X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: Alex Nash <nash@Mcs.Net>
CC: Curtis Bray <cbray@best.com>, freebsd-hackers@freebsd.org
Subject: Re: malloc() problems in children after using rfork()
References: <Pine.BSF.3.95.971121151935.2450J-100000@Jupiter.Mcs.Net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Alex Nash wrote:
> 
> On Fri, 21 Nov 1997, Curtis Bray wrote:
> 
> > Hi,
> >
> >   I'm trying to use rfork(RFPROC | RFMEM) so that all the children can
> > share the same address space with their parent.
> >
> >   If I have multiple children issuing mallocs the children seem to core
> > dump.  Once I turn the RFMEM flag off I have no problem mallocing (but
> > of course I loose the shared address space).  Anyone know what I could
> > be doing wrong here?  Do I have to put semaphores around every malloc??
> > I hope that's not the case...  Thanks in advance!
> 
> The only locking malloc() performs is pthread_mutex_lock/unlock in the
> libc_r version.  The non-threaded version provides no locking at all.
> 
> Alex

I just saw the other email

he's using 2.2.5
rfmem don't work in 2.2.x.
well it DOES but it only shares EXISTING memory.
new allocations are not shared..