From: rgr AT rio DOT sci DOT ccny DOT cuny DOT edu (Roger Kuhlman) Subject: Re: pinfo_mutex? 22 Jun 1997 17:35:49 -0700 Sender: mail AT cygnus DOT com Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <199706230004.UAA15668.cygnus.gnu-win32@rio.sci.ccny.cuny.edu> Original-To: popiel AT pecan DOT snugharbor DOT com (T. Alexander Popiel) Original-Cc: gnu-win32 AT cygnus DOT com In-Reply-To: from "T. Alexander Popiel" at Jun 22, 97 09:48:28 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Original-Sender: owner-gnu-win32 AT cygnus DOT com > > I am frequently getting the message: > > cygwin: Cygwin32: Catastrophic fail - unable to Create pinfo_mutex > > when spawning shells (for autoconfiguration, make builds, etc.). > Does anyone know what this is symptomatic of? Does anyone know > a way to fix it? > > - Alex > - > For help on using this list (especially unsubscribing), send a message to > "gnu-win32-request AT cygnus DOT com" with one line of text: "help". > There are two issues. 1) if you are using NT, or Win95 you are not going to get much joy with less than 64mb real memory, and about another 64mb of swap when compiling with recursive makes or recursive autoconfiguration schemes. You also have to watch out with recursive operations that open files and then spawn processes. I have occasionally had cross linking of files when a spawn failed. 2) During recursive makes(makes that call make, the preproccessor, etc). I have on three occasions had a general protection fault that brought about an OS crash with a diagnostic screen--the equivalent of a Unix panic. The filesystem came up dirty under those conditions, and I lost the files that were still in buffers when that happened. This is not really the fault of the gnuwin32 stuff. This will not occur on any Unix, even if the version of gnumake does not check load before doing a recursion(some of the older versions of gnumake did produce process table full exceptions resulting in the orderly death of the calling process i.e. an exit from the loader). For your own sanity, use a -j 1 argument to make, and make sure $MAKEFLAG is -j 1 in recursive calls. This assures that make will not spawn unimpeded. Perhaps Microsoft can address the issue in Memphis and NT5. Good Luck, Roger Kuhlman e-mail: rgr AT rio DOT sci DOT ccny DOT cuny DOT edu - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".