Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm 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 Date: Tue, 30 Nov 2004 11:27:44 -0800 From: David Hinds To: cygwin AT cygwin DOT com Subject: Re: A vexing installation problem Message-ID: <20041130192744.GA3172@sonic.net> References: <20041129071451 DOT GA15469 AT sonic DOT net> <6 DOT 2 DOT 0 DOT 14 DOT 0 DOT 20041129115158 DOT 046c9120 AT pop DOT prospeed DOT net> <20041129184442 DOT GA30302 AT sonic DOT net> <20041129185016 DOT GA32114 AT trixie DOT casa DOT cgf DOT cx> <20041129220649 DOT GA26502 AT sonic DOT net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041129220649.GA26502@sonic.net> User-Agent: Mutt/1.4.2i On Mon, Nov 29, 2004 at 10:32:09PM -0500, Christopher Faylor wrote: > Cygwin initialization code isn't particularly hard to debug. You just > set breakpoints and debug it like any other part of cygwin. It's > actually easier to debug than most other pieces because there aren't > multiple threads running. When I strace the same program several times, the trace doesn't always end at the same spot. While the bug may be in the DLL initialization code, the intermittent and inconsistent behavior smells like a race condition. I later figured out that when these programs fail, they exit with an "access violation" error code. I tried running one under the Visual Studio debugger and it appeared that the access violation was in kernel32.dll. With no backtrace information available. The affected system is a dual Xeon workstation. -- Dave -- 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/