X-Recipient: archive-cygwin@delorie.com X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Message-ID: <4B9AAB39.7080302@gmail.com> Date: Fri, 12 Mar 2010 20:59:37 +0000 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: Cygwin 1.7: Concurrency Issue with Shared State Initialization References: <20100312162736.GS6505@calimero.vinschen.de> <20100312172801.GV6505@calimero.vinschen.de> In-Reply-To: <20100312172801.GV6505@calimero.vinschen.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com On 12/03/2010 17:28, Corinna Vinschen wrote: > Hang on. This endless loop has nothing to do with Cygwin code. The > addresses show that we're outside of Cygwin, which is in the 0x61xxxxxx > address range. 0x7dxxxxxx is probably somewher in a Windows DLL. That'll be WFMO, I'd bet. So it's consistent with the suggestion that we're somewhere deeper down the call stack doing the low_priority_sleep, and the top-level in shared.cc is looping forever. > and I can't > figure out any situation in which this could result in an endless loop > *unless* the process which is doing the initial initialization has been > forcefully teminated during initialization. Or thrown an exception, or called api_fatal, I would expect. cheers, DaveK -- 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