This is the mail archive of the
mailing list for the Cygwin project.
Re: YA call for snapshot testing
On Jan 25 01:28, Christopher Faylor wrote:
> On Tue, Jan 24, 2012 at 10:03:05PM -0800, Kevin Layer wrote:
> >Larry Hall (Cygwin) wrote:
> >>> > This problem is killing me. I'm currently looking msysgit + GnuWin32
> >>> > because I just can't take the crashes of bash.exe and git.exe anymore.
> >>> > In my testing, so far, I've never seen msysgit or the bash that comes
> >>> > with it crash. Why is it that cygwin has this problem but msysgit
> >>> > does not? It's an honest question and I'm not trying to be
> >>> > provocative. I've been a cygwin user since before Red Hat acquired
> >>> > them, and the above statement makes me really sad.
> >>> Have you tried running rebaseall?
> >Absolutely. After updating cygwin, I reboot and run rebaseall -v
> >first thing.
> FYI, as far as I can tell the stack trace that you provided did not seem
> to come from the 20120123 snapshot.
I concur. This:
7 [main] bash 1732 c:\cygwin\bin\bash.exe: *** fatal error - couldn't allo
cate heap, Win32 error 487, base 0x990000, top 0x9F0000, reserve_size 389120,
allocsize 393216, page_const 4096
looks suspiciously like from 1.7.9 or a snapshot before 2011-05-16.
After that, Cygwin allocates the heap by default in a totally
different spot, 0x20000000. And if that doesn't work, it will move
the heap position *up* in the process VM, not down. And only if there
is no continuous memory block of 384K beyond 0x20000000 at process start,
which is pretty unlikely, it will allocate a stack of 4 Megs at a spot
which the OS decides about.
Therefore, a snapshot after 2011-05-16 which tries to allocate 384 Megs
in a spot below 0x20000000 is practically impossible.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple