Message-ID: <4ACDCA99.9090400@cwilson.fastmail.fm>
Date: Thu, 08 Oct 2009 07:18:49 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Thread related crash
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

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