Date: Mon, 1 Mar 1999 12:18:21 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: David Greenman <dg@root.com> Cc: Luoqi Chen <luoqi@watermarkgroup.com>, freebsd-hackers@FreeBSD.ORG, mjacob@feral.com Subject: Re: Panic in FFS/4.0 as of yesterday - update Message-ID: <199903012018.MAA47735@apollo.backplane.com> References: <199903011940.LAA16503@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:>> New bugs found ( and not fixed ):
:>>
:>> * exec_map can only hold 16 exec'ing processes at once. It needs a
:>> counter and a sleep/wait.
:>>
:>> Sometimes when I ran Matt J's 'breakit' script, a background program
:>> would 'Abort trap' out instantly on startup because more then 16
:>> were doing an exec at once. This can only occur in a low-memory
:>> or heavy-I/O situation.
:>>
:>There could also be potential deadlocks when all 16 processes hold a lot in
:>exec_map and then all of them try to allocate more from exec_map (for loading
:>elf interpreter). The simplest solution is to use a separate map.
:
: Allocations from exec_map are done using kmem_alloc_wait() and frees are
:done using kmem_free_wakeup, so they already sleep/wakeup as appropriate when
:the map is full.
:
:-DG
:
:David Greenman
:Co-founder/Principal Architect, The FreeBSD Project
Hmm. Something is going on. Four times now I have gotten 'Abort trap'
on some of the processes Matt J's STEST script starts -- it starts
up 50 processes at once. The abort occurs prior to main() being called.
There is NOTHING in the code that can generate this trap othe then the
exec code ... and only if the exec fails after the vmspace is destroyed.
So the question is: What is causing exec to fail?
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903012018.MAA47735>