Date: Mon, 22 Dec 1997 00:55:43 +0100 From: pb@fasterix.freenix.org (Pierre Beyssac) To: ache@nagual.pp.ru (???????????????) Cc: current@FreeBSD.ORG (FreeBSD-current) Subject: Re: vfork (exec?) bug confirmation Message-ID: <19971222005543.CE52615@@> In-Reply-To: <Pine.BSF.3.96.971221212932.238A-100000@ache.relcom.ru>; from ??????????????? on Dec 21, 1997 21:37:23 %2B0300 References: <Pine.BSF.3.96.971221212932.238A-100000@ache.relcom.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
??????????????? writes:
> I can confirm that following script cause immediate kernel page fault
> even with very recent -current.
>From what I understand, it looks more and more like a vfork() bug.
The bug in execve() may be explained by a weird stack left by
vfork() which causes arguments passed by value to fail.
Some more information I got from ddb:
- the panic occurs when the child csh calls execve();
- the parent csh is, at this moment, waiting in "ppwait".
The main differences between vfork() and fork() are flags RFMEM
and RFPPWAIT when calling fork1(). Disabling "fast_vfork" causes
the first flag to be disabled and the bug to disappear. So the bug
is probably in one of the sections that handle RFMEM. I see only
one in fork1():
/*
* Divorce the memory, if it is shared, essentially
* this changes shared memory amongst threads, into
* COW locally.
*/
if ((flags & RFMEM) == 0) {
if (p1->p_vmspace->vm_refcnt > 1) {
vmspace_unshare(p1);
}
}
Shouldn't something be done also when RFMEM is set?
--
Pierre Beyssac pb@fasterix.frmug.org pb@fasterix.freenix.org
{Free,Net,Open}BSD, Linux : il y a moins bien, mais c'est plus cher
Free domains: http://www.eu.org/ or mail dns-manager@EU.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971222005543.CE52615>