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 Date: Mon, 4 Jul 2005 14:10:57 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: Freeze in perl script after cygwin upgrade 1.5.17 -> 1.5.18 Message-ID: <20050704181057.GA19583@trixie.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com References: <42C96709 DOT 9030005 AT scytek DOT de> <20050704174424 DOT GA18735 AT trixie DOT casa DOT cgf DOT cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050704174424.GA18735@trixie.casa.cgf.cx> User-Agent: Mutt/1.5.8i 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/