This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Thread related crash
- From: Charles Wilson <cygwin at cwilson dot fastmail dot fm>
- To: cygwin at cygwin dot com
- Date: Thu, 08 Oct 2009 07:18:49 -0400
- Subject: Thread related crash
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?
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.
cgywin-1.7, debug build as of 20091007.
--
Chuck
--
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