This is the mail archive of the
mailing list for the Cygwin project.
Re: Thread related crash
- From: Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Thu, 8 Oct 2009 09:48:22 -0400
- Subject: Re: Thread related crash
- References: <4ACDCA99.email@example.com>
- Reply-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...
>_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:
>_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
>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
So why isn't this a problem with the current version of insight then?
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple