Mail Archives: cygwin/2005/07/28/09:59:45
On Thu, 28 Jul 2005, Dave Korn wrote:
> ----Original Message----
> >From: Krzysztof Duleba
> >Sent: 28 July 2005 08:00
>
> > Igor Pechtchanski wrote:
> >> On Thu, 28 Jul 2005, Krzysztof Duleba wrote:
> >>
> >>> I am not. I understand that this is how it should work
> >>> theoretically, but I've _checked_ that on a couple of Cygwin boxes
> >>> with different versions of cygwin1.dll and gcc. All of them didn't
> >>> really care that heap_chunk_in_mb was undefined in the registry.
> >>> Perl, on the other hand, do care.
> >>
> >> Actually, you're right. Perhaps it depends on what kind of malloc the
> >> program uses (i.e., whether it uses the Cygwin builtin malloc, or
> >> something else).
> >
> > That's strange. How could Perl use something essentially different than
> > malloc? I thought it would all come down to brk or sbrk.
>
> There's a real bug here. I think it could be a consequence of the
> recent cygload changes, but OTOH it could have already been there: I
> haven't looked at the details of that patch, or the cvs history of that
> part of the code, but we're in the same area. Here's how it goes:
>
> Regardless of their malloc implementations, Perl and C both rely on
> Cygwin's sbrk(...) implementation. The code that grows the heap looks
> like this:
>
> if ((VirtualAlloc (cygheap->user_heap.top, newbrksize, MEM_RESERVE, PAGE_NOACCESS)
> || VirtualAlloc (cygheap->user_heap.top, newbrksize = commitbytes, MEM_RESERVE, PAGE_NOACCESS))
> && VirtualAlloc (cygheap->user_heap.top, commitbytes, MEM_COMMIT, PAGE_READWRITE) != NULL)
> {
> cygheap->user_heap.max = (char *) cygheap->user_heap.max + pround (newbrksize);
> goto good;
> }
>
> Here, cygwin is trying to extend the heap by allocating the maximum of
> (requested size, heap_chunk_in_mb) bytes of memory contiguously to the end
> of the current heap (or the minimum of the two if that fails), and it is
> this that is failing in the perl case, and succeeding in the case of
> compiled C code; I stepped through it in insight and watched the calls fail.
> This must be because there is something allocated by perl that fragments
> the process' memory map that isn't allocated when running a C program.
>
> I've been on the track of it. By running that perl example
>
> ------------------------<snip>------------------------
> perl -e '$a="a"x(200 * 1024 * 1024);'
> ------------------------<snip>------------------------
>
> under windbg, and breakpointing VirtualAlloc, I was able to intercept the
> call that tries to extend the heap: here's the stack, showing the args to
> the function call
> [snip bug analysis]
> clearly showing that there's ~900meg of contiguous free space after the heap
> except for a single page allocated at 0x28140000, thus preventing it from
> growing any larger than (0x28140000 - 0x204d6000) ~= 125meg.
Hmm, but shouldn't this code fail regardless of the value of
heap_chunk_in_mb? Why does increasing heap_chunk_in_mb make this succeed?
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ pechtcha AT cs DOT nyu DOT edu
ZZZzz /,`.-'`' -. ;-;;,_ igor AT watson DOT ibm DOT com
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA
--
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/
- Raw text -