Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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 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 > > 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