I found what seems to be the cause of the resource leak, at least for
the XP computers involved. Aventail Connect (a VPN client) seems to
have been involved since removing it from the system fixed the problem.
It seemed odd that using msconfig to start up with only essential
drivers and no ser
I've used msconfig to turn off all services/drivers at startup, and the
memory leak persists. Kernel memory goes up slowly, Physical memory
goes down faster, and Handles/Threads/Processes remain steady.
I'm not aware of any software installed which might have an effect on
spawned processes. A
Thanks for the input so far. Task Manager shows memory usage slowly
creeping up as the makefile below is run. I've verified this on two XP
laptops and one w2k desktop. The memory never comes back, and it
doesn't take long to max out a 512Mb/768Mb machine. Might take a bit
longer if you've g
Attached is a very simple makefile which demonstrates the problem.
There's a leak either in make itself or in the spawning of
subprocesses.
Beware! this will likely lock up your machine, or at the very least
prevent you from launching any new processes.
Simply type "make" with this makefile i
No, no virus scanners here.
On Apr 13, 2005, at 10:33 AM, Brian Ford wrote:
On Wed, 13 Apr 2005, Timothy Wall wrote:
See attached. The make starts failing when it can't invoke some
subprocesses.
Just a WAG. Are you running a virus scanner like Agnitum Outpost
(sp?)?
--
Unsubscribe
See attached. The make starts failing when it can't invoke some
subprocesses.
On Apr 12, 2005, at 3:48 PM, Larry Hall wrote:
So are there any more error message lines other than just:
/bin/bash: fork: Resource temporarily unavailable
/bin/bash: line 1: /usr/bin/find: Resource temporarily unavail
No joy. Tried replacing cygwin1.dll with the one from 1.5.15 (snapshot
build); still get the same error.
On Apr 12, 2005, at 1:53 PM, Larry Hall wrote:
Try it with the latest release Cygwin package (1.5.14). If that
doesn't
help, you might want to try it against the upcoming release (1.5.15) b
Looks like the "rebaseall" only delayed the problem. I still get the
error, only now it takes a few more invocations of the build.
I will try a dev build next.
On Apr 12, 2005, at 2:14 PM, Larry Hall wrote:
At 01:59 PM 4/12/2005, you wrote:
I updated both to 1.5.14-1. I then downloaded and ran
I updated both to 1.5.14-1. I then downloaded and ran rebaseall and
rebooted, which seems to have fixed the problem (at least the
invocations which reproducibly triggered the problem no longer do so).
rebaseall failed a few times before I remembered I had cygwin sshd
running. It also did not
I've got a "make" process that's pretty complex and does many recursive
invocations (at most 4 deep, though). With some additions to the
build, I seem to have recently crossed over some threshold which now
causes the build to use up all available process resources, so nothing
more can be run.
Since cygwin will kill a subprocess if you hit ctrl-break manually,
I've written a little utility that allows you to send ctrl-break
directly to the java process from any other console on the same
machine.
Note that if java is invoked directly from the shell, cygwin gets the
ctrl-break and sti
;
> If your program does not use cygwin then investigate the currently active
> thread "bash/cmd CTRL-C problem...".
>
> cgf
>
> On Tue, Jan 08, 2002 at 12:31:47PM -0500, Timothy Wall wrote:
> >I'm trying to get some consistent behavior under the command shell
I'm trying to get some consistent behavior under the command shell and cygwin,
tho' without much luck so far. I'd like to know if there's a canonical
SIGINT/SIGTERM handling convention for console processes (taking cygwin into
account, or barring that for invocations in cmd.exe only).
The import
13 matches
Mail list logo
