delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2000/10/17/11:42:55

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
Date: 17 Oct 2000 11:38:55 -0400
Message-ID: <20001017153855.2548.qmail@lizard.curl.com>
From: Jonathan Kamens <jik AT curl DOT com>
To: earnie_boyd AT yahoo DOT com
CC: starksb AT ebi DOT ac DOT uk, cygwin AT sources DOT redhat DOT com
In-reply-to: <20001017152857.19990.qmail@web114.yahoomail.com> (message from
Earnie Boyd on Tue, 17 Oct 2000 08:28:57 -0700 (PDT))
Subject: Re: rxvt SEGV (Win98, 1.1.5s/2000-10-08)
References: <20001017152857 DOT 19990 DOT qmail AT web114 DOT yahoomail DOT com>

>  Date: Tue, 17 Oct 2000 08:28:57 -0700 (PDT)
>  From: Earnie Boyd <earnie_boyd AT yahoo DOT com>
>  
>  The best way to help is to get the CVS source and build it (it
>  takes ~30 minutes on my PII Compaq armada to do the make).  The
>  new-cygwin1.dll that is produced contains debugging symbols and is
>  about 3.5M large.  You'll copy this to the cygwin1.dll in the bin
>  directory.  Then using common debugging methods figure out what's
>  wrong.  If you use strace be sure to use the most recent version as
>  some bug fixes to strace itself have occurred.

Surely you're not asserting that "using common debugging methods [to]
figure out what's wrong" within the complex internals of Cygwin is an
easy task.

In fact, we have a developer here who did that a couple years ago and
sent a whole slew of fixes to the Cygwin maintainers to various race
conditions which manifested themselves on MP machines.  His opinion is
that the Cygwin developers have always been a bit sloppy about
handling the issues that arise on MP machines.  He has also asserted
that debugging Cygwin internals is very hard, certainly not something
that can be done easily "using common debugging methods."

We're a start-up.  We're in the middle of getting a product out the
door.  My management would hardly appreciate it if I took a week off
from the work that I'm supposed to be doing to learn how the Cygwin
internals work to debug a complicated MP race condition which
intermittently causes our builds to crash.

Mind you, I'm not saying that we don't contribute to open source.  In
fact, our company's culture is very open-source oriented, and we find,
fix and contribute fixes to problems in various open-source packages
all the time.  I'm saying that this particular debugging task is one
that is too time-consuming for anyone in my company to take on right
now.

Short of becoming a Cygwin expert, is there anything I can do to make
it possible for the people who are already Cygwin experts to debug
this problem?

  jik

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019