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
From: svoboda AT cs DOT cmu DOT edu
Reply-To: svoboda AT cs DOT cmu DOT edu
To: cygwin AT cygwin DOT com
Subject: Cygwin memory profiling tools?
Date: Thu, 10 Feb 2005 14:10:19 -0500
User-Agent: KMail/1.7.2
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200502101410.20219.svoboda@cs.cmu.edu>
Source-Info:  Sender is really svoboda+@mandal.lti.cs.cmu.edu

I have the task of porting a big C++ application to Windows XP. It
currently runs on Linux and AIX, and builds using g++ 3.2 &
makefiles. Fortunately, the big application contains a lot of small
test code, so I have been able to do small incremental builds and test
them in Windows before moving on to bigger pieces. I am thus using
Cygwin/G++ for the porting.

Unfortunately I have hit a snag that seems to bar any workarounds. It
seems that most any time I load a DLL that uses new/delete, I get a
crash, usually 'signal 11'.  The crash goes away if I don't load the
DLL, but that's not possible for the big application.

This same code that crashes under Cygwin runs under Linux, and
generates 0 errors under valgrind on Linux.

My question is, what debugging tools are there on cygwin or Windows
that would help here? Valgrind seems to not be available, and gdb only
tells me that the coredump occurred during a destructor (or after the
program ended.) How do I find out what code is screwing up memory
allocation?

~Dave

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/