1.5.19: fork: resource temporarily unavailable
Fri Jan 27 18:13:00 GMT 2006
On Fri, 27 Jan 2006, Corinna Vinschen wrote:
> On Jan 26 22:48, Igor Peshansky wrote:
> > On Fri, 20 Jan 2006, Igor Peshansky wrote:
> > > First reported in <http://cygwin.com/ml/cygwin/2005-12/msg00817.html>.
> > > Here's a short summary: fork failes because pinfo doesn't
> > > initialize, pinfo reports a loop because PID_EXITED is set. Still
> > > getting this with the latest CVS build.
> > > [snip]
> > > I would like to figure out what's causing this. My main question
> > > is: am I on the right track here? What else should I look for?
> > Am I on the right list here? I am getting consistently plagued by
> > this after I run a particular script at work (that creates and
> > sometimes kills lots of short-lived processes). Unfortunately, I'm
> > not at liberty to post the script itself, and it's possible that
> > there's something peculiar to my setup that's causing this issue.
> > But I'd like to get to the bottom of this.
Thanks for replying, Corinna.
> I'm not overly familiar with pinfo stuff myself. Could you reduce the
> script to the bare minimum to have a reproducible testcase, at least?
Believe me, I've tried. It apparently involves creating (and killing)
many Win32 processes, as well as Cygwin processes. Somewhere in there
Cygwin's process information table gets trashed (I think). I'm guessing
it could have something to do with Cygwin stub processes for Win32
> Does that only happen under high load in, say, an ssh session?
It happens under high memory consumption (my normal story), but not a
particularly high CPU load...
> Maybe you're just suffering from the small heap problem Chris reported
> some weeks ago (the one which requires to change the registry key).
I thought about it. My heap_chunk_in_mb is already set to 1024 (I have 1G
of RAM). Is that the value you were referring to?
> Otherwise, if that's not the problem, maybe you should try to vary the
> number of iterations in the pinfo::init loop to some arbitrary high
> value. If the problem persists, it's likely not the loop itself which
> is causing problems.
I think it's not the loop itself. The process info structures are from
(apparently) legitimate processes that have nothing to do with the script
(e.g., one of the iterations reported "vim" as the program name, and the
script doesn't run vim). Is there an easy way to monitor the state of the
process table (I could print the whole thing, of course, but there's got
to be a better way)?
> Do you have any other error message in strace which would give a hint
> about, say, a process hanging while exiting or something like that?
Nope, the processes in the pinfo printouts seem to actually exit properly,
as they don't show up in "ps" by the time the script is started... The
funny thing is that the script completes for me once with no problems, but
subsequent invocations result in the "fork: resource temporarily
unavailable" problem, which indicates (to me) that something probably goes
wrong with the process table. I believe the processes in that process
table are the ones that were started after the first successful invocation
of the script.
Another possibility is that UnmapViewOfFile is not doing the right thing
somehow, or isn't completing properly before the procinfo structure is
reused. Just grasping at straws here... I'll add some tracing for this
and report back...
|\ _,,,---,,_ email@example.com | firstname.lastname@example.org
ZZZzz /,`.-'`' -. ;-;;,_ Igor Peshansky, Ph.D. (name changed!)
|,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"
More information about the Cygwin-developers