Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <2FC2818A89E01D408136CACA2EF121713F580C@mailserv.notts.climax.co.uk>
From: Jon Jansen <JonJ AT climax DOT co DOT uk>
To: cygwin AT cygwin DOT com
Subject: RE: Unable to allocate heap
Date: Wed, 3 Sep 2003 11:10:36 +0100 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

CreateFileMapping() is fine. I think the problem is a race condition in
shared_info::heap_chunk_size(). The heap_chunk member is in
process-to-process shared memory, and in my case both find and xargs enter
the function at approximately the same time and attempt to initialise the
same instance of heap_chunk.

One possible outcome is that one of the processes is returning heap_chunk at
the point where the other process has just set it to the (in-megabytes)
value obtained from the registry (hence "heap_chunk_size 384"). Another
possible outcome is that one of the processes executes the <<= 20 just after
the other process has already set the (in bytes) heap_chunk value. This
could give rise to "heap_chunk_size 0" which other correspondents were
seeing before the stop-gap was added in a recent version of shared.cc.

One solution would be to use a local variable instead of heap_chunk itself,
and then assign to heap_chunk at the last gasp. I suppose this would only
work if the assignment to heap_chunk could be guaranteed to be atomic.
Perhaps a mutex would be safer?

-----Original Message-----
From: Jon Jansen [mailto:JonJ AT climax DOT co DOT uk]
Sent: 01 September 2003 17:17
To: cygwin AT cygwin DOT com
Subject: Unable to allocate heap


I get the following error running CygWin find and xargs from within a TCL
script:

    Error executing 'C:/cygwin/bin/find TempDir/QACData -name *.lock -type f
-print0 | xargs -0r rm -r'...
    c:\cygwin\bin\xargs.exe: *** unable to allocate heap, heap_chunk_size
384, Win32 error 0

The error is intermittent and I haven't been able to reproduce it outside
the TCL script (whether from bash, cmd, tclsh, whatever).

There's similar prior art in the archives, but this one has the crucial
difference that the reported heap_chunk_size is small but non-zero.

I've had a look through the relevant source (shared.cc, heap.cc), and my
initial thought was that shared_info::heap_chunk_size() was returning a
rogue size for some reason. It seems that the memory-zeroing behaviour of
Win32 CreateFileMapping() is used to initialise shared_info::heap_chunk to
zero. Is CreateFileMapping() completely trustworthy in this respect?


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/