Mail Archives: cygwin/2001/04/16/14:24:14
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
- Raw text -