This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Thread related crash

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


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]