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
Subject: Re: cygwin bughunt (out-of-the-box debugging)
Date: Fri, 21 Jan 2005 15:58:53 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID: <79F81D5F4790D344B05F489CE2AC8AB71095D6@dubexdc03.dubex.net>
Content-class: urn:content-classes:message
From: "David Dindorp" <ddi AT dubex DOT dk>
To: <cygwin AT cygwin DOT com>
Note-from-DJ: This may be spam
Content-Transfer-Encoding: 8bit

Bill Hughes wrote:

> I don't think I'm putting this very well, but it may make the FAQ
> easier if the standard advice is to load the snaphot and use that for
> debugging, it removes a separate layer of potential problems in
> building the dll.

And there's still the issue that problems that are notoriously hard to
debug, ie. transient/sporadic issues such as race conditions are subject
to timing differences and therefore miniscule changes in code.  A
different compile will yield different results, and will seemingly
correct some issues in some environments even if the bug in question has
not been fixed.

So even if it is usually the best thing to grab the newest snapshot to
see if the problem should by chance be fixed, I think there is some
problems that need to be debugged against the version on which they were
discovered.

Having a ready and available debug version built on the same PC and
based on the same source as the stock Cygwin binaries is in this case
the sane option, IMHO.  (A separate symbols file that doesn't interfer
with the binaries would as mentioned earlier be even better.)

Personally, I of course have other reasons for wanting a ready-made
debug version.  Foremost, because I have Cygwin installed in production
environments where I can't just go around and replace binaries with
snapshot versions as I please.
Things here and there could potentially break from release to release,
and it seems that they tend to do :-)

I can very well understand and accept if I contact the mailing list and
get told, "if you're not using the latest snapshot, you're gonna have
to locate and pin your bugs yourself".  It could even be a FAQ entry.

But having a ready-made version available just makes life so much easier
for people like me who
 - Don't have a clue how the Cygwin sources are arranged
 - Have no idea of the proper way compile it
 - Couldn't fix a compile error if the solution slapped me in the face
 - Will probably do something wrong, end up with a maimed binary and
   spam the list with new stupid questions on how to do proper compiles
   and fix bizarre compile-related problems.

I'm of course happily ignoring the whole aspect of "leaving out the
debug version forces a bunch of people to learn the intimacies of the
Cygwin source so that they are able to compile it, thereby increasing
the number of potential Cygwin developers".

Honestly I think that it's better to provide the debug version and
thereby point people to the right location in the source code, than
to force people to spend weeks trying to make a succesful compile
first.  Opinions probably vary on this..

To sum it up,
Pros:
 + Debugging race conditions et al possible
 + Debugging production systems possible
 + Shorter time to locate bugs?
 + Saner bug reports?

Cons:
 - Less people forced to learn themselves to compile Cygwin

From my point of view, out-of-the-box debugging would be SO nice.


Regards
/david

PS. I'm new to the newsgroup, and already being cocky.  I'm sorry.


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