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 -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple