From owner-freebsd-current  Sun Sep 20 11:06:49 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id LAA04637
          for freebsd-current-outgoing; Sun, 20 Sep 1998 11:06:49 -0700 (PDT)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA04609
          for <current@FreeBSD.ORG>; Sun, 20 Sep 1998 11:06:44 -0700 (PDT)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id EAA30519;
	Mon, 21 Sep 1998 04:06:15 +1000
Date: Mon, 21 Sep 1998 04:06:15 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199809201806.EAA30519@godzilla.zeta.org.au>
To: dfr@nlsystems.com, phk@critter.freebsd.dk
Subject: Re: vfork and malloc
Cc: current@FreeBSD.ORG
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>>Is it safe to call malloc in the child process after a vfork?  I have been
>>trying to debug a rare fault in make which goes away when I change the
>>vfork() in src/usr.bin/make/compat.c to fork().  After the vfork, it calls
>>execvp() which allocates memory via strdup().
>
>It may not be safe to do if the mmap(2)'ed area used for the page table
>isn't also shared at that time.

Hmm.  It's not safe to call malloc() from execle(), since execle() is
supposed to work in signal handlers.  malloc() is called from execle() :-(.
This is fixed in OpenBSD (using alloca()).  It's interesting that
execl() is not required to work from signal handlers, and still calls
malloc() in OpenBSD.  I suppose this is because the implicit environ for
execl() might be under construction, while the caller is supposed to
be responsible for passing a valid environ to execle() - just passing
`environ' is invalid in signal handlers.  Calling execvp() from signal
handlers is more obviously invalid - it needs to call getenv(), and
getenv() is not required to work in signal handlers.

Bruce

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