Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Date: Mon, 16 Apr 2001 22:20:44 +0400
From: egor duda <deo AT logos-m DOT ru>
X-Mailer: The Bat! (v1.45) Personal
Reply-To: egor duda <cygwin AT cygwin DOT com>
Organization: deo
X-Priority: 3 (Normal)
Message-ID: <81181541863.20010416222044@logos-m.ru>
To: Christopher Faylor <cygwin AT cygwin DOT com>
Subject: Re: What's a good stable snapshot DLL?
In-reply-To: <20010416135126.C17910@redhat.com>
References: <8F23E55D511AD5119A6800D0B76FDDE11E0F0A AT cpex3 DOT channelpoint DOT com>
 <200104161740 DOT NAA13650 AT envy DOT delorie DOT com> <20010416135126 DOT C17910 AT redhat DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi!

Monday, 16 April, 2001 Christopher Faylor cgf AT redhat DOT com wrote:

>>> This is probably a FAQ.  Are the cygwin1.dll snapshots generated
>>> with debug symbols such that I'll get more information in my Dr Watson
>>> reports?  If not, do I need to build my own with VC++ 6.0 such that I
>>> can pull up the debugger when (if) I get the access violations?
>>
>>Snapshots are built with gcc, not vc, so even if there's debug
>>information in it, DrWatson won't see it.
>>
>>If you're going to be debugging the dll, you should get the sources
>>from CVS and built it yourself, and use gdb to debug.  That will give
>>you the best environment.  However, you'll need to build a copy of gdb
>>that uses a "debug" version of cygwin, so as to avoid using the dll
>>you're debugging.  Chris - perhaps you should create a web page on how
>>you debug the dll?  You've had the most experience with this.

CF> Yeah, I've been thinking about doing this.  Most of the debugging seems
CF> like common sense, to me.  You set breakpoints and hope that they get
CF> hit...

i think almost everything starts to seem like common sense after you
spent several days debugging some non-trivial bug in cygwin1.dll :-)
At least, from my experience.

CF> Or, you

CF> set CYGWIN=error_start=x:\path\to\gdb.exe

CF> and let cygwin pop up a copy of gdb when there is a SIGSEGV or something.

or, you

set CYGWIN_SLEEP=10000

and hurry to attach to process while it's sleeping in startup code.
or, if some long-running script crashes right in the middle, you
sprinkle debug_printf()s all around functions you suspect and run this
script under strace.
or, if it's heap memory problem, you build cygwin1.dll with
MALLOC_DEBUG and watch it crawls and assert()s when heap's corrupted.

Speaking of MALLOC_DEBUG, i've almost made it as simple as supplying
'--enable-malloc-debug' to configure, and hopefully will submit
patches soon.

DJ just made a good point about building special copy of gdb which
uses different dll, so i think the following trick is worth
mentioning:
- make sure  x:\path\to\special\gdb\ is not in path
- place known-working copy of cygwin1.dll and normal unmodified copy
of gdb.exe into x:\path\to\special\gdb\
- create x:\path\to\special\gdb\start_gdb.cmd containing

set CYGWIN_TESTING=1
x:\path\to\special\gdb\gdb.exe %1 %2

and then

set CYGWIN=error_start=x:\path\to\special\gdb\start_gdb.cmd

Egor.            mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple