From: "Dave Korn" <dave.korn@artimi.com>
To: <cygwin@cygwin.com>
Subject: RE: cygwin + windows update = lock up (W2K SP4)
Date: Wed, 3 May 2006 13:02:31 +0100
Message-ID: <000401c66ea9$7491abf0$a501a8c0@CAM.ARTIMI.COM>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <4457C0DB.F0093A96@dessent.net>
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

On 02 May 2006 21:28, Brian Dessent wrote:

> Dave Korn wrote:
> 
>> ...because for some reason, despite attaching the debugger, and despite
>> having frozen every other thread and only left one running, every time I
>> try to single step it, it just carries on running as if I'd told it to
>> continue. Dunno why except perhaps the debugger isn't keen to try and let
>> you single-step through debugger-related functions in case it breaks
>> itself or something.  This may call for a full two-machine kernel remote
>> debugging session in the end :-(
> 
> It's a real shame that Russinovich is apparently aware of this defect
> but remains uninterested in dealing with it past calling it a Cygwin
> deficiency.

  It's not his defect, let's get that straight; there's absolutely nothing
wrong with calling "RtlQueryProcessDebugInformation (pid, PDI_BACKTRACE,
buffer);" on any arbitrary pid.

  I really do think it *is* because we do funny (meaning non-standard and even
perhaps slightly risky) stuff in DllMain/DLL_THREAD_ATTACH.  munge_threadfunc
is pretty high on my list of suspects right now.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


--
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/