Re: What's a good stable snapshot DLL?

[egor duda <deo at logos-m dot ru>]

Hi!

Monday, 16 April, 2001 Christopher Faylor cgf@redhat.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@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19



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