Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list 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> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "David Dindorp" To: X-Rescan: True X-IsSubscribed: yes Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id j0L9lmek004450 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 | 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/