X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 	tests=AWL,BAYES_00,SPF_PASS
X-Spam-Check-By: sourceware.org
Message-ID: <4A0790ED.1080100@gmail.com>
Date: Mon, 11 May 2009 03:43:57 +0100
From: Dave Korn <dave DOT korn DOT cygwin AT googlemail DOT com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: How to detect a cygwin thread?
References: <9f8a01cd0905091706s6944a639m8da2f943212cc178 AT mail DOT gmail DOT com> 	 <loom DOT 20090510T004554-316 AT post DOT gmane DOT org> 	 <9f8a01cd0905100245m16838bb9w3c6e494d4a03a4cb AT mail DOT gmail DOT com> 	 <loom DOT 20090510T184100-821 AT post DOT gmane DOT org> 	 <20090510202132 DOT GB25909 AT ednor DOT casa DOT cgf DOT cx> 	 <9f8a01cd0905101533i2902636aub172298be61599a5 AT mail DOT gmail DOT com> 	 <20090510233629 DOT GC25909 AT ednor DOT casa DOT cgf DOT cx> <9f8a01cd0905101707x2b91f1edg33ae17ec82ab722e AT mail DOT gmail DOT com>
In-Reply-To: <9f8a01cd0905101707x2b91f1edg33ae17ec82ab722e@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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

Piotr Wyderski wrote:
> I don't know the reason, just report the program's
> behaviour. But to provide you more context: this
> code is a critical error handler. All it has to do is:
> 
> 1. immediately stop the world in a nice way,
> as this thread is all about. When "sig" is suspended,
> no more points follow.

  I think the only safe way to do this is to invoke the debugging APIs, e.g.
DebugActiveProcess:

http://msdn.microsoft.com/en-us/library/ms679295(VS.85).aspx

> 2. dump detailed stack traces + module list +
> the emergency stop reason description to
> the set of log files;
> 
> 3. call std::abort in order to generate a core file for post-mortem analysis.

  There's a cygwin utility called 'dumper.exe' that generates a gdb-debuggable
core dump of a running process; take a look at how it works.  You could hack
that into a task monitor for your critical process.  It could be running at a
higher priority and waiting on a named event; then in your application, when
you want to invoke the critical error handler, you just signal the event - you
should be immediately pre-empted in favour of the now-ready higher priority
process, and it can call DebugActiveProcess to freeze (and then core-dump) the
monitored process.  With a following tailwind, you should get an even more
immediate and accurate freezing of your application's state than if one of the
app's own threads is engaged in multiple system calls to enumerate and suspend
threads one-by-one.

    cheers,
      DaveK


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