X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=wcU6d4uikT6mDruInoFAwNdXc2kTldhnzw6zmUNTge86vQzaPvsb/
	xgWS2ZUFvoR3KMl4ha/rEZzMEvtJ29GRo+jrBl/78CYYeIdHkIjmv8usp24LMiTB
	Zb76yt73UN34U96c0LBL3BQHrnVR1AW95abQhWL2RSHy50mj8NP7nI=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=tzVlO85SGWbE1vf1qECgkSwrmEQ=; b=IYasUEZyV2ROs2/aySaOS5EuljUi
	PXlyg1Lk5Ud3TE2JmZ5SjwaSBilcscBpsgpTHENgKx5fPwKtP3vnPUHEnGATjAPU
	CNsOWF4/8DUAUVt+FguveEhraqqKqQ8uD/PWEbOKTL87B/X2jcoglX2jQck6DrnK
	XKIr9ZZqNu8nSgE=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-0.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2
X-HELO:	mho-01-ewr.mailhop.org
X-Mail-Handler:	Dyn Standard SMTP by Dyn
X-Report-Abuse-To:	abuse AT dyndns DOT com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information)
X-MHO-User:	U2FsdGVkX1+C7XfT+sBXzb2KDDB6e6Yb
Date:	Mon, 9 Dec 2013 15:47:59 -0500
From:	Christopher Faylor <cgf-use-the-mailinglist-please AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Signal occasionally causes thread inside win32 api to be suspended?
Message-ID:	<20131209204759.GA1675@ednor.casa.cgf.cx>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<52A4AE10 DOT 8080303 AT dronecode DOT org DOT uk>
MIME-Version:	1.0
In-Reply-To:	<52A4AE10.8080303@dronecode.org.uk>
User-Agent:	Mutt/1.5.20 (2009-06-14)

On Sun, Dec 08, 2013 at 05:36:16PM +0000, Jon TURNEY wrote:
>I don't really understand the intricacies of cygwin signal delivery,
>but I see that it can suspend the target thread to determine if it's in
>a safe place to deliver the signal (outside a win32 API call).  I think
>that sometimes the thread is not correctly resumed.
>
>This appears to be the cause of been a long-standing problem with the
>X.org X server on cygwin, which we work around by disabling
>smart-scheduling (no great loss), but I've only just recently
>understood enough about the problem to produce a STC.
>
>If you run the attached for a while, it stops.  According to Process
>Hacker, the main thread is in the suspended state, inside ntdll.dll.
>e.g.:

I think I have worked around the problem: calling GetModuleName for the
address associated with ntdll.dll while the thread is suspended can cause
the program (thread?) to hang.

This should be rectified in today's snapshot.

Thanks, as always, for the test case.

cgf

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

- Raw text -