This is the mail archive of the cygwin 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: Bug identified [was RE: perl - segfault on "free unused scalar"]


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@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.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/


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