This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygthread::cygthread() hang


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?

Pierre


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]