Date: Thu, 8 Oct 2009 09:48:22 -0400
From: Christopher Faylor <cgf-use-the-mailinglist-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Thread related crash
Message-ID: <20091008134822.GD14389@ednor.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <4ACDCA99 DOT 9090400 AT cwilson DOT fastmail DOT fm>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4ACDCA99.9090400@cwilson.fastmail.fm>
User-Agent: Mutt/1.5.20 (2009-06-14)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On Thu, Oct 08, 2009 at 07:18:49AM -0400, Charles Wilson wrote:
>I'm getting some weird crashes with threads.  When a thread exits, I'm
>getting a SEGV in _cygtls::remove.  That is, when the thread function
>returns, it ends up in cygtls::call2 (e.g. at B, below).  Oddly, if I
>set a break point at A, it is never hit...
>
>void
>_cygtls::call2 (DWORD (*func) (void *, void *), void *arg, void *buf)
>{
>  init_thread (buf, func);         <<< A >>>
>  DWORD res = func (arg, buf);
>  remove (INFINITE);               <<< B >>>
>  /* Don't call ExitThread on the main thread since we may have been
>     dynamically loaded.  */
>  if ((void *) func != (void *) dll_crt0_1
>      && (void *) func != (void *) dll_dllcrt0_1)
>    ExitThread (res);
>}
>
>But the wierd thing is, once I "return" to ::call2, this = 0x0. That's
>very bad, and when remove() is called, it does:
>
>void
>_cygtls::remove (DWORD wait)
>{
>  initialized = 0;
>
>where initialized is a member variable of _cygtls: that is,
>this->initialized. But this is 0x0.
>
>I have an idea why this is happening: I'm managing these threads
>manually using the windows API calls: CreateThread, WaitForSingleObject,
>SetEvent, etc. They are NOT actually started by cygwin's thread
>launching facilities (e.g. pthread). However, is it possible that cygwin
>is overzealously inserting the _cygtls::call2() function into the return
>frame stack?  Does cygwin manipulate the TIB, even for threads created
>by direct calls to CreateThread?

Uh, yeah.  If you are not using Cygwin methods to start threads then it
is entirely likely that there will be problems, just like if you use
non-Cygwin methods to do I/O.

>That is: CreateThread() goes thru a bunch of win32 functions, and then
>transfers control to the passed-in function pointer (the main thread
>function).  But, when the main thread function returns, it does NOT go
>directly back to those w32 funs, but instead detours into
>_cygtls::call2.  But, since _cygtls didn't actually create the thread --
>*this is null.
>
>Any suggestions? (Other than an STC. I'll put one together after I get
>some sleep).
>
>This is coming up because any tcl app that I've built -- including
>insight -- always dies on exit, as tcl is shutting down its various
>utility threads.

So why isn't this a problem with the current version of insight then?

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