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
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: Re: cygwin bughunt (more FAQ stuff)
Date: Fri, 21 Jan 2005 10:47:20 +0100
Message-ID: <79F81D5F4790D344B05F489CE2AC8AB7109577@dubexdc03.dubex.net>
From: "David Dindorp" <ddi AT dubex DOT dk>
To: <cygwin AT cygwin DOT com>
Content-Transfer-Encoding: 8bit

Joshua Daniel Franklin wrote:

> Well, how about this then:
> [snip]


Here's my shot at what would've helped me a lot when I initially faced
problems.  Of course providing as much info as below will only leave
you with more newbies crying 'cygwin_split_path() : 0x61073e06' or such.

+ More information. Good for newbies (like me).
+ Basically I think it was two different questions, so splitted them up.
- Lengthier.


I may have found a bug in Cygwin, how can I debug it?

You can use GDB [link to GDB description?] to debug the failing
application.
Using the 'backtrace' command within GDB will tell you which, if any,
cygwin functions are being executed at the time that your application is
failing.

GDB works on core files generated during segmentation faults or using
the
'dumper.exe' utility.  It can also debug live processes.
In order to properly use GDB, you must have debugging symbols enabled,
and
(when using a core dump file) preferably run GDB on the machine where
the
failure occurred.  See [next item] and [next next item].


GDB does not show any function names (only "???") when debugging core
files?

In order for GDB to look up function names, it needs to be able to find
binary
files that match the version(s) that was used when the core dump was
generated.
This usually means that the easiest way to get the correct output is to
run
GDB on the machine where the crash originally occurred. Also avoid
upgrading
that particular machine (Cygwin and OS) until you are done debugging.

If you need to debug on a different machine, you can get the relevant
DLL and
EXE files from the original machine and stuff them in the same paths as
they
originally resided.  Run GDB on the core file and run 'info dll' to get
the
names of the files needed.  Alternatively, if using 'dumper.exe', do a
verbose
run and grab the filenames like this:
 dumper -d <filename> <winpid> | grep "added module".


The symbols in gdb are missing or look funny (eg. are just hex values)?

Debugging symbols are stripped from distributed Cygwin binaries, so any
symbols that you see in gdb are basically meaningless. It is also a
good idea to use the latest code in case the bug has been fixed, so you
will need to follow the instructions at [/faq/faq_3.html#SEC102] to
build your own debugging version. You can also contact the mailing list
for pointers (a simple test case that demonstrates the bug is very
welcome).


Mangle and/or ridicule as you see fit :-).


--
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/