Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Message-ID: <3BA5BA28.C1F47119@goingware.com>
Date: Mon, 17 Sep 2001 04:54:00 -0400
From: "Michael D. Crawford" <crawford AT goingware DOT com>
Organization: GoingWare Inc. - Expert Software Development and Consulting
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: debugging threads in CygWin?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have a program written using Windows threads using the Win32 API with CygWin. 
It's an application built with the ZooLib cross-platform applications framework,
which you can get at http://zoolib.sourceforge.net/

It uses threads (in a C++ wrapper) and atomic math extensively.  The atomic math
is written in inline assembler, with a different version provided for each
supported compiler and processor.

I have it almost working, but it crashes in mysterious ways.  I'm suspecting
that it's a problem with the atomic math or something to do with the threads.

When I look at it in CygWin's gdb, I always get a crash in the same place, but I
don't think I am seeing the code that is crashing.  Instead what I think is
going on is that some objects are destroyed as they go out of scope, and
reference counts are being decremented, and maybe even semaphores are released,
and so all kinds of stuff is going on that I don't see in gdb.

GDB has some support for threads, but it doesn't seem to be helping me.

One thing that I see happening is that if I set a breakpoint where an object is
declared on the stack, and step into its constructor and back out, my crash does
not happen.  This is part of what's making me think my problem is with thread
handling; I believe each time one steps gdb lets all the running threads
continue to run and then stops them.

I know this is kind of vague but can anyone give me any suggestions on how to
debug this?

I haven't done this but I understand single stepping through the assembly for
atomic arithmetic can screw it up.

Something helpful I found tonight is that I can disable the use of COM by
defining:

#define NOCOMATTRIBUTES

in the header file that ZooLib includes globally (zconfig.h).  If I didn't do
this, my compile would fail because I wasn't using -fvtable-thunks.  If I did
use -fvtable-thunks, my program jumps into outer space on the first virtual
function call because there is a binary incompatibility between my compiled code
and the runtime library.  The ultimate solution to this is to build the runtime
libraries with -fvtable-thunks on but I haven't figured out how to do that yet.

The main think I need to do to get ZooLib built under CygWin is disable COM and
comment off the places in ZooLib's code where it registers and unregisters its
windows as drag & drop handlers.

Now if I could get this bug fixed I think it should work and I'd be really
stoked.

Mike
-- 
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com
crawford AT goingware DOT com

  Tilting at Windmills for a Better Tomorrow.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/