X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org To: cygwin AT cygwin DOT com From: Eric Blake Subject: Re: [1.7] deleting in-use directories Date: Thu, 9 Apr 2009 17:30:26 +0000 (UTC) Lines: 31 Message-ID: References: <20090409170228 DOT GA5231 AT calimero DOT vinschen DOT de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit User-Agent: Loom/3.14 (http://gmane.org/) X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: 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 Corinna Vinschen cygwin.com> writes: > Incredible but true. It was an alignment problem with a local buffer > in the function which moves the directory to the bin when a sharing > violation occurs. > BYTE infobuf[sizeof (FILE_NAME_INFORMATION) + 32767 * sizeof (WCHAR)] That's an awfully big buffer to be stack-allocating. It's bigger than a system page, which means if you are nearing stack overflow, then call rmdir(), your application could suffer from silent termination rather than orderly SIGSEGV stack overflow when it accesses beyond the guard page. Didn't a recent gcc version add a -W option to warn about stack frames larger than a certain size? > This seems to be a new problem with gcc-4. As long > as I built Cygwin with gcc-3, I never had this problem. Weird, indeed. > > Please test the latest from CVS. It should fix your problem. I'll let you know how it goes. Meanwhile, I've patched the autoconf testsuite to avoid triggering the problem in the first place. -- Eric Blake -- 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/