pinfo_mutex?

pinfo_mutex?

[T. Alexander Popiel]

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@cygnus.com" with one line of text: "help".

Re: pinfo_mutex?

[Roger Kuhlman]

> 
> 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@cygnus.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@rio.sci.ccny.cuny.edu
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: pinfo_mutex?

[David Coe]

T. Alexander Popiel wrote:
> 
> 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?
> 

Running mkpasswd > /etc/passwd fixed this for me.

-- 
Dr David Coe			     \=\
58 Fairlawn Drive, East Grinstead     \=\   Tel +44 1342 326860
West Sussex, RH19 1NT, United Kingdom  \=\  Fax +44 1342 316019
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

You can't stop progress

[root]

> > 
> > I am frequently getting the message:
> > 
> > cygwin: Cygwin32: Catastrophic fail - unable to Create pinfo_mutex  
> > 
> 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 

64MB of RAM just to run an autoconf+some make. This is new to me.
I didn't expect to see a message like this in 1997, only in 1999 2000.
A program REQUIRING 64MB of RAM!!!!
I thought that the first program that woould had those requirements would be
a monstruous database/expert system/GUI program. 

NO. It was GNU Make!!!

Congratulations to cygnus for establishing this record! I wonder when
a Hello world program will need 1Gigabyte of RAM to start and some
terabytes of disk to be stored...




-- 
Jacob Navia	Logiciels/Informatique
41 rue Maurice Ravel			Tel 01 48.23.51.44
93430 Villetaneuse 			Fax 01 48.23.95.39
France
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: pinfo_mutex?

[Geoffrey Noer]

T. Alexander Popiel wrote:
> 
> I am frequently getting the message:
> 
> cygwin: Cygwin32: Catastrophic fail - unable to Create pinfo_mutex

I don't know why this was happening, but it appears to be fixed
in the latest development version so I expect it will be fixed in the
next release...  (Sorry I can't give you any real explanation).

-- 
Geoffrey Noer
noer@cygnus.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: You can't stop progress

[Ian]

At 08:51 AM 6/23/97 +0200, "root" shaped the electrons thusly:
[snip[
>64MB of RAM just to run an autoconf+some make. This is new to me.
>I didn't expect to see a message like this in 1997, only in 1999 2000.
>A program REQUIRING 64MB of RAM!!!!
[snip]

I haven't had any memory-related problems with 16MB or 24MB and
w95; configure and make have always run slowly, but they run (well,
they did until last week -- configure scripts now cause my machine
to crash, but I'm working on that :)

>-- 
>Jacob Navia	Logiciels/Informatique

-- 
Ian Reinhart
ian@parti.inforum.org

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: You can't stop progress

[Sheik]

Jacob,
I think the poster of that 64 Meg stuff was a little over-enthuasitic.

I run win95 with 16 megs of ram, and I have no problems with any/all
cygnus stuff. In fact, I have gone and compiled ircii, and ssh using the
cyngus tools, and I have never ran into any problems with 16 megs of ram.
(I never noticed my .swp file, but VC++ usually makes 95 make a 30+ meg
swap file, cygnus HAS to be better than that!!)

Now, obviously under NT, you might need more ram, since the overhead from 
the OS is much larger, but I suspect 24 or 32 megs of ram would be fine.


Scott



On Mon, 23 Jun 1997, root wrote:

> > > 
> > > I am frequently getting the message:
> > > 
> > > cygwin: Cygwin32: Catastrophic fail - unable to Create pinfo_mutex  
> > > 
> > 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 
> 
> 64MB of RAM just to run an autoconf+some make. This is new to me.
> I didn't expect to see a message like this in 1997, only in 1999 2000.
> A program REQUIRING 64MB of RAM!!!!
> I thought that the first program that woould had those requirements would be
> a monstruous database/expert system/GUI program. 
> 
> NO. It was GNU Make!!!
> 
> Congratulations to cygnus for establishing this record! I wonder when
> a Hello world program will need 1Gigabyte of RAM to start and some
> terabytes of disk to be stored...
> 
> 
> 
> 
> -- 
> Jacob Navia	Logiciels/Informatique
> 41 rue Maurice Ravel			Tel 01 48.23.51.44
> 93430 Villetaneuse 			Fax 01 48.23.95.39
> France
> -
> For help on using this list (especially unsubscribing), send a message to
> "gnu-win32-request@cygnus.com" with one line of text: "help".
> 
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: You can't stop progress

[Paul Shirley]

In message < 3.0.1.32.19970623075147.00824830@192.160.61.2 >, Ian
<ian@parti.inforum.org> writes
>At 08:51 AM 6/23/97 +0200, "root" shaped the electrons thusly:
>[snip[
>>64MB of RAM just to run an autoconf+some make. This is new to me.
>>I didn't expect to see a message like this in 1997, only in 1999 2000.
>>A program REQUIRING 64MB of RAM!!!!
>[snip]
>
>I haven't had any memory-related problems with 16MB or 24MB and
>w95; configure and make have always run slowly, but they run (well,
>they did until last week -- configure scripts now cause my machine
>to crash, but I'm working on that :)

gcc really likes having >32Meg of ram and has done for as long as I can
remember *on the PC*, I was shocked at the obvious difference moving
from 40 Meg of 70ns ram to 32 Meg of 60ns ram made... it slowed djgpp
down noticeably. gcc is extremely resource greedy, on Unix this hardly
matters but Windoze seems to have serious problems coping with it.

-- 
Paul Shirley
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: pinfo_mutex?

[Hmmmz]

On Sun, 22 Jun 1997, Roger Kuhlman wrote:
> 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.

I run NT Server on a Pentium with 32mb ram and about 40 swap spread out on
two drives and it runs fairly quickly. I've run 95 too on the same
machine, and things do run faster (cause 95 uses less ram) even with 32 mb
swap. Running 95 on a 486 with 20mb ram & 20mb swap, things were painfully
slow, but that was most probably due to the fact I was using a 486, no
major disk swapping.
 
> 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.

I've only seen a "blue screen" once on NT, and that was when someone ran
WinNuke on me (nt dumping core.. what fun..), gnu-win32 has never brought
down my system.  Using alt-ctrl-del to close programs on Win95 has brought
major unstability to my system and sometimes rebooted the system, but make
itself hasn't done that to me.
 
> 	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.
*shrug*
> 	Perhaps Microsoft can address the issue in Memphis and NT5.

LOL, Microsoft fixing bugs... man that's a good way to get a laugh.

- alex

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: You can't stop progress

[Hmmmz]

On Mon, 23 Jun 1997, Paul Shirley wrote:

> gcc really likes having >32Meg of ram and has done for as long as I can
> remember *on the PC*, I was shocked at the obvious difference moving
> from 40 Meg of 70ns ram to 32 Meg of 60ns ram made... it slowed djgpp
> down noticeably. gcc is extremely resource greedy, on Unix this hardly
> matters but Windoze seems to have serious problems coping with it.
> 
> -- Paul Shirley

I think this is mainly an OS thing and not gcc.  I've noticed that NT with
32mb ram acts like 95 with 8, not to say that 95 is that fast, but... if
you don't have gobs and gobs of ram at your disposal, 95 and gcc work
together pretty well with about 32 megs of ram.

- alex

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: You can't stop progress

[Paul Shirley]

In message < Pine.BSI.3.96.970623141538.21729B-100000@fish.hooked.net >,
Hmmmz <garbanzo@hooked.net> writes
>I think this is mainly an OS thing and not gcc.  I've noticed that NT with
>32mb ram acts like 95 with 8, not to say that 95 is that fast, but... if
>you don't have gobs and gobs of ram at your disposal, 95 and gcc work
>together pretty well with about 32 megs of ram.
>
>- alex

Yes, this is the problem. gcc assumes that the underlying OS has good
memory management (the wasteful 2^n malloc system assumes the OS will
optimise the wastage for instance). Unfortunately Windoze seems not to
be good at managing memory. The surprise is that using >32 megs improves
gcc under windoze. I have no native win32 software that speeds up
detectably above 32M apart from gcc, I think the underlying assumptions
implicit in gnu/Unix software just stretch windoze very seriously.

-- 
Paul Shirley
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".