From owner-freebsd-hackers@FreeBSD.ORG  Mon Jul 21 12:32:19 2003
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id D29E737B401
	for <freebsd-hackers@freebsd.org>;
	Mon, 21 Jul 2003 12:32:19 -0700 (PDT)
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 5D58943FBD
	for <freebsd-hackers@freebsd.org>;
	Mon, 21 Jul 2003 12:32:19 -0700 (PDT)
	(envelope-from dillon@apollo.backplane.com)
Received: from apollo.backplane.com (localhost [127.0.0.1])
	by apollo.backplane.com (8.12.9/8.12.6) with ESMTP id h6LJWJVI027713;
	Mon, 21 Jul 2003 12:32:19 -0700 (PDT)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.12.9/8.12.6/Submit) id h6LJWJuM027712;
	Mon, 21 Jul 2003 12:32:19 -0700 (PDT)
Date: Mon, 21 Jul 2003 12:32:19 -0700 (PDT)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200307211932.h6LJWJuM027712@apollo.backplane.com>
To: Pawel Jakub Dawidek <nick@garage.freebsd.pl>
References: <20030720235759.GJ437@garage.freebsd.pl>
	<20030721181805.GA43543@garage.freebsd.pl>
	<20030721191622.GC43543@garage.freebsd.pl>
cc: freebsd-hackers@freebsd.org
Subject: Re: VM problem...
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Jul 2003 19:32:20 -0000


:	end =3D vm->vm_daddr + ctob(vm->vm_dsize);
:	obreak(vm, end + size);
:	vm_map_protect(&vm->vm_map, end, end + size, VM_PROT_READ);
:
:And vm_map_protect() will create new map entry (it should, right?)
:with entry->start =3D end and entry->end =3D end + size.
:
:But what happend with those entries when execve() is called?
:Because process' map catched before execve() doesn't exists after
:execve() is called. So maybe those entries (with VM_PROT_READ) are
:reused somehow?
:
:THANKS!
:
:--=20
:Pawel Jakub Dawidek                       pawel@dawidek.net

    Hmm.  Well, when a process forks the vm_map_entry's fork along with
    it.  The underlying VM objects remain shared but become copy-on-write.

    It sounds like whatever you are doing is messing up the user stack, and
    the program is bus-faulting when it can't write to the user stack.
    All sorts of things have to write to the user stack, including the
    signal trampoline code and even execve().

    The fault address you reported earlier, 0xbfbffc20, is on the user stack. 

						-Matt