This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Freeze in perl script after cygwin upgrade 1.5.17 -> 1.5.18


On Mon, Jul 04, 2005 at 01:44:24PM -0400, Christopher Faylor wrote:
>On Mon, Jul 04, 2005 at 12:42:49PM -0400, Volker Quetschke wrote:
>>After upgrading cygwin yesterday I get the following reproducible hang
>>in a perl script starting an external program.
>>
>>This is the perl script that works with the 1.5.17 cygwin dll and hangs
>>with 1.5.18:
>
>Did you also see this with snapshots?

While waiting for the answer to the above rhetorical question, I thought
I'd add an observation: Rather than go to a lot of effort running things
and getting straces which may or may not illustrate the problem, it is
ALWAYS a much better plan to reduce things to a simple test case which
can be reproduced by people who may or may not use strace to debug the
problem.

The division of labor should be like this:

The reporter more or less understands the code for which they are
reporting problems so they should be able to reduce things, as much as
possible, to a test case which reproduces the problem.  With a test case
in hand, you can then hand off the problem to someone who understands
cygwin and who will be able to use the simple test case to debug the
problem.

Attempting to bypass the test case step and do the cygwin maintainer's
"job" of generating strace output is not as likely to be a worthwhile
endeavor as producing the test case itself.  You are not likely to jump
start the debugging process by doing this.  Even if the strace output
was useful, the debugger would have no real way of knowing if they fixed
the problem without a test case.

The theory here is that a bug reporter shouldn't need to spend any time
trying to debug cygwin (via strace) unless they really are interested in
learning about cygwin internals.  That means that the most profitable
thing a bug reporter can do is create a test case.

In a similar "why bother?" vein, it is generally not useful to provide
"me too" observations unless the "me too" contains additional details to
aid in debugging the problem.  An additional detail is not "it also
fails when I run this other large application" unless you can point to
some similarity in the two failing applications or provide any other
detail which would help track the problem down.

We normally do trust that people who report problems are actually having
problems and having multiple people report that they have the same
problem with no additional debugging details beyond "it dies for me when
I run this other big application" is not generally going to be useful.

cgf

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]