Mail Archives: cygwin/2001/10/09/03:23:49
---- 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?
> regression - downgrading to cygwin-1.3.2-1 makes debugging fine. There
> were several other messages stating that debugging doesn't work with
> 1.3.3 and changing to 1.3.2 fixes the problem. So it seems that it is
> in fact a bug. It doesn't mean that cygwin developers must start
> working on it immediately and I (as, I guess, other bug reporters)
> don't expect it, but it should be registered as a known bug and bug
> reports should be treated like efforts to provide help to someone who
> will eventually work on fixing it.
I'm amazed this meme (about bugs reports and solutions) persists.
This is IMO of course...
Firstly, I classify bugs into two groups:
obvious and non-obvious. By this I mean that an obvious bug is one that
when the offending function (or perhaps group of closely related fn's)
is re-read carefully, the bug is identified and can be solved. A
non-obvious bug is one where debugging detail (a strace perhaps) is
needed, or if that does not provide enough detail, then actual debugging
is needed.
So this really gives us 4 different bug types, if you like.
1-Obvious) The faulty code is visually identifiable once a clear
description of circumstances is provided. (ie when sending SIGINT to an
.exe application running inside of gdb 5.0.1 foo happens. attached is a
cygcheck and ..)
2-Visible with detail) On request from a developer, or perhaps provided
as a courtesy a strace of the fault as it occurs, in controlled
circumstances, with a minimal program (ie if the program spends 30
minutes fluffing around. the strace has been trimmed) a developer is
able to pin-point the fault in the source.
3-Debugging needed, reproducible with detail) The fault can be
reproduced on any system, with minor effort required (building package
foo does not count as minor). A cygwin developer using debugging tools
can then locally identify and solve the problem.
4-Debugging needed, not reproducible) The fault is unable to be
reproduced by a cygwin developer with minor effort, or may not be
reproducible at all. The cygwin developers can do nothing other than
offer guidance for the affected individual to solve the problem locally.
Now, How much information is needed to classify a bug in cygwin? Well,
for someone like Chris or Corinna, very little. If there is not enough
info to classify the bug, then _someone_ (not necessarily Chris or
Corinna) will ask for more info. Then based on their internal feel for
the fault, a solution will be recommended. Thus you will see Corinna ask
for a strace, or Chris say "I think I've fixed it please try snapshot
foo".
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..
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.
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.
What does all of this rant mean for *you* on the cygwin list?
If you report a bug, and get given suggestions for debugging it, then in
the opinion of the person making the suggestion, it is (in my category
system) a 4 or possibly a 3. At this point, you have two choices:
a) Ignore the bug. Go do something else. Don't whine, don't post about
how it doesn't occur back a version in the hope that the bug will
magically become easier for us to solve: We've already checked the code,
and the changelog for obvious related info.
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.
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/
- Raw text -