X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-0.2 required=5.0 tests=AWL,BAYES_00,TW_YG,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org To: cygwin AT cygwin DOT com Subject: Re: YA call for snapshot testing In-reply-to: <20120125062835.GD18425@ednor.casa.cgf.cx> References: <20120122054719 DOT GB28773 AT ednor DOT casa DOT cgf DOT cx> <20120122055300 DOT GB657 AT ednor DOT casa DOT cgf DOT cx> <4F1BBB0F DOT 2020009 AT gmail DOT com> <20120122165705 DOT GA10996 AT ednor DOT casa DOT cgf DOT cx> <4F1C5F56 DOT 8070208 AT gmail DOT com> <20120122193306 DOT GA12886 AT ednor DOT casa DOT cgf DOT cx> <4F1C759D DOT 9010704 AT shaddybaddah DOT name> <29235 DOT 1327446059 AT freon DOT franz DOT com> <4F1F422E DOT 9040507 AT cygwin DOT com> <13884 DOT 1327471385 AT freon DOT franz DOT com> <20120125062835 DOT GD18425 AT ednor DOT casa DOT cgf DOT cx> Comments: In-reply-to Christopher Faylor message dated "Wed, 25 Jan 2012 01:28:35 -0500." Date: Wed, 25 Jan 2012 11:05:02 -0800 Message-ID: <19613.1327518302@freon.franz.com> From: Kevin Layer X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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'll investigate that. >> >> >>> If not, install the rebase package and >> >>> read its README to get the proper procedure for running rebaseall. This >> >>> is a classic error message indicating colliding DLL addresses. Rebaseall >> >>> (and sometimes peflags) are the prescribed solution in these cases. >> >>> >> >>> If that doesn't solve the problem, a complete problem report would be >> >>> helpful. >> > >> >I have no idea how to make a reproducible test case of my system, >> >composed of 50+ repos, is large and not open source. We have shell >> >scripts that we use to apply git commands to each repo. >> > >> >One thing I've mentioned before: the problem became much worse when we >> >switched development to a 16-core machine. It's running Server 2008 >> >R2. >> > >> >Does anyone at Red Hat run on such a large-core machine? >> >> Why does that matter? This is a free software project staffed by one >> Red Hat person and a lot of people from other institutions. I'm really not sure what you're getting at... I was merely asking if the developers of Cygwin have tested on a 16-core machine. I think my problems all started when I and my developers started using it. >> >The machine has been memtested, btw, and msysgit on the exact same >> >repos operates flawlessly, in my tests so far. All other non-cygwin >> >software on the machine works perfectly, too. >> > >> >If you think a bug report without a reproducible test case would be >> >useful, let me know what info I can provide. >> >> Hmm. Can you actually conceive of a situation where, when reporting a >> bug, a reproducible test case is NOT useful? No, but I'm not a Cygwin expert, so I thought I'd ask. >> Barring a reproducible test case you could provide some of the >> information that I asked for in the thread that you're responding to. >> And, we always want to see cygcheck output with the additional details >> asked for. I'll read over the thread again and post it shortly. Kevin -- 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