Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <014901c150bb$970ecac0$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Roman Belenov" <rbelenov AT yandex DOT ru>
Cc: <cygwin AT cygwin DOT com>
References: <3BC1CF2E DOT 7177 DOT 33050F17 AT localhost> <3BC1B8C0 DOT C1E58D08 AT rowman DOT com><20011008115635 DOT A18826 AT redhat DOT com><5 DOT 0 DOT 2 DOT 1 DOT 2 DOT 20011008123354 DOT 00b186b0 AT sen-mail DOT gtri DOT gatech DOT edu><upu7yoxmz DOT fsf AT yandex DOT ru> <006501c15093$a36abae0$0200a8c0 AT lifelesswks> <ug08tp3uj DOT fsf AT yandex DOT ru>
Subject: Re: Perl 5.7.2
Date: Tue, 9 Oct 2001 22:11:55 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime: 09 Oct 2001 12:18:04.0486 (UTC) FILETIME=[724DCE60:01C150BC]

----- Original Message -----
From: "Roman Belenov" <rbelenov AT yandex DOT ru>
To: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>


> "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au> writes:
>
> > ---- Original Message -----
> > From: "Roman Belenov" <rbelenov AT yandex DOT ru>
> > To: "Ken Thompson" <ken DOT thompson AT gtri DOT gatech DOT edu>
> >
> >
> > > Ok, let's stop quarreling and return to the facts. On my system
> > > debugging with cygwin-1.3.3-2 is also not possible - debuggee
receives
> > > unknown signals before reaching main(). I reproduced it on the
empty
> > > program (after encountering on the real one). It is indeed a
> >
> > Any program? or perl programs? Are you running bleedperl as John is?
>
> Empty C program - main(){}

Thanks. I now realise you had posted more detail before - sorry for
getting you to repeat yourself. At this post, AFAIK noone who routinely
hacks on cgwin is able to repeat your problem - but egors suggestion for
reading the how-debugging-works file is very likely to let you gather
enough info to get a solution happening.

> > The order I listed the categories above in is important: a category
4
> > bug will NEVER be fixed by a cygwin developer. If it is, then it
> > actually was a category 3, or 2..
>
> So it means that cygwin is destined to be buggy - my experience (not
> with cygwin) says that there are usually many bugs that require
> significant efforts to be reproduced still they can affect many users
> in certain circumstances.

Yes and no. The category 4 I used is when no developer _can_ reproduce.
The amount of effort is immateriel - if I am simply unable to make the
bug happen, and collaboration with the bug reporter is insufficient for
me to identify the bug in the code, then the only way it can be solved
is in situ in the faulty environment.

> > The amount of work needed on the part of the fault reporter
increases
> > >From 1 thru 4. If you report a bug and it's a 1, the report may be
all
> > thats needed, but if it's a 4 expect to learn gdb, and cygwin's
source
> > before it will get fixed.
>
> Sorry, but usually users don't have enough time or experience to fix
> bugs themselves, it's a job of developers. In case of open source
> software users just don't have right to demand anything from
> developers, but the dinstinction between users and developers remains
> the same (of course, anybody can volunteer to switch from being a user
> to being a developer, but not anyone would like to do it).

Sure I understand that. Fortunately _most_ bugs are not in cat 4 (or
cygwin would look a lot different that it does!). However a fair number
are in cat 3 - requiring a time commitment from the users to perform
debugging steps for the developers who haven't reproduced the fault, and
not enough is known about it to attempt reproducing it. For example,
with your debug problem, I can't reproduce it. Debugging on win2k sp2,
cygwin 1.3.3-2 worked fine for me. If you can generate enough detail
about the cygwin state at the time of the fault, then maybe I(or egor or
Chris or Corinna or ..... (no insult to those not mentioned!)) can
reproduce it, and having done so fix it. Or perhaps even fix it sight
unseen given sufficient data. At the moment however, the comments from
Chris (who AFAIK knows this aspect of cygwin best) indicate that he has
no inkling of the fault, and random data won't help - thus the onus on
the user to provide detail.

I do agree with the core of your point though - simply pointing out that
it is a very grey area between users of the kind "What's the any key"
and developers of the kind "variable foo does not need to be set via
Interlocked functions because cache coherency on all DP coppermine
chipsets is a worst case of 1200 cycles between write and flush and we
are guaranteed to wait 4000 cycles anyway before acting on the value"<--
(yeah, I'm not down at that level ok, just making a point :})

> > This is not a matter of policy, or choice, or resources, its a
simple
> > matter of fact. Every software project acts like this: if a bug is
non
> > reproducible, then the onus is on the submitter to solve the bug
> > AND/OR answer all questions from the developers about the bug - if
> > they are putting it in my category 3.
>
> So bugs in your category 4 will persist until some user will debug it
?
> It makes quality of software product depend too much on its users.

You are assuming something about the volume of cat four bugs. I think
cygwin has seen 3 or 4 (at most!) in the last 2 years. Many bugs are in
my cat 3, which still requires the use of gdb and a debug build of
cygwin to provide reasonable detail to the developers.

> Well, in this particular case information that the bug doesn't exist
> in the previous version should be helpful for developers since they
> can't reproduce the bug. And amount of bug reports should be helpful

Yes. One report thereof :].

> because it shows how widespread are the system configurations with
> buggy behaviour and so may lead to understanding of the reason behing
> it. It's not much, but it's still a bit of potentially useful
> information.

I see what you are suggesting there, but for that info to have any
significance, the ratio of users of cygwin to cygwin subscribers MUST be
exactly the same in each potential variable. i.e. if 10% of cygwin users
are subscribed and report bugs, but 50% of NT users are subscribed, and
only 5% of win95 users, then those stats are going to be skewed. Also, I
don't ahve *anything* to do with bug prioritisation. If it's a pthreads
bug, I solve it ASAP, or put it in the 'future' bucket if its not a bug
in existing code but rather a why-doesn't-x--exist.

> > b) Follow the suggestions. Ask for help on following the
suggestions.
> > The bug will either become obvious to the developers during the
ensuing
> > dialogue, or you will find the fault, and be able to identify it
> > precisely rather than generally, which usually gives the developers
> > enough detail to create a test case themselves, at which point it
> > becomes a 3, and you *may* get let off the hook.
>
> Ok, I usually try to do it if the efforts required are reasonable from
> my point of view.

That's all we can ask :].

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/