cygthread::cygthread() hang

Christopher Faylor
Wed Apr 9 17:19:00 GMT 2003

On Wed, Apr 09, 2003 at 01:14:44PM -0400, Pierre A. Humblet wrote:
>Christopher Faylor wrote:
>> On Wed, Apr 09, 2003 at 12:55:53PM -0400, Pierre A. Humblet wrote:
>> >Joe Buehler wrote:
>> >>
>> >> Christopher Faylor wrote:
>> >>
>> >> > Yep.  I guess it's possible that there are more leaks than just the
>> >> > stack one.
>> >>
>> >> OK, I think I know what is going on.  The stack address for terminated
>> >> threads is walking up through memory until it hits the top and then
>> >> CreateThread() fails.  So the thread stack is not being freed.
>> >>
>> >> Looking at the API documentation, it looks like VirtualFree() is not being
>> >> used correctly.  The VirtualQuery() function is returning a region of size
>> >> 4096.  So probably that is all that is committed, the rest is reserved,
>> >> and VirtualFree is only freeing the committed memory, since everything has
>> >> to be in the same state.  I'll call VirtualFree() twice like the docs say
>> >> and see if that fixes it.
>> >
>> >Shouldn't it simply be MEM_RELEASE? Right now the committed memory would
>> >change state to reserved, no freed.
>> I think, as Joe implied, it should be MEM_DECOMMIT followed by
>> MEM_RELEASE, right?
>MEM_RELEASE will both decommit and free.
>But I don't really know which state we want to end up in.
>Why is "reserved" bad, as long as we eventually recommit it?

I was reading older documentation apparently.  As Joe says, current MSDN says

"If any pages in the region are currently committed, the function first
decommits and then releases them."

My older documentation says this:

"If only part of the pages in the original reserved region are
committed, you must first call VirtualFree to decommit the committed
pages and then call VirtualFree again to release the entire block."


More information about the Cygwin-developers mailing list