Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Date: Fri, 14 Sep 2001 21:34:07 +0400 From: egor duda X-Mailer: The Bat! (v1.53 RC/4) Reply-To: egor duda Organization: deo X-Priority: 3 (Normal) Message-ID: <142188273973.20010914213407@logos-m.ru> To: Jonathan Kamens CC: cygwin-developers AT cygwin DOT com Subject: Re: Useful details about the Make SEGVs In-Reply-To: <20010914171959.5066.qmail@lizard.curl.com> References: <20010912173945 DOT 25925 DOT qmail AT lizard DOT curl DOT com> <20010914002450 DOT B25486 AT redhat DOT com> <20010914170318 DOT 4862 DOT qmail AT lizard DOT curl DOT com> <20010914131117 DOT D2709 AT redhat DOT com> <20010914171959 DOT 5066 DOT qmail AT lizard DOT curl DOT com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi! Friday, 14 September, 2001 Jonathan Kamens jik AT curl DOT com wrote: JK> Do you think I should try rerunning the "make -j2" under strace? probably. strace is good when you've partially identified the cause of the problem, and want to trace how it comes that info in pipe is lost. The power of strace is that you can add your own debugging output in arbitrary places of dll code and see, for example, how many bytes are in pipe. than you grep an strace and see where those bytes gone. JK> How about running it with a cygwin1.dll compiled with malloc debugging JK> (ouch! that'll hurt)? that'll certainly hurt :) i afraid that we won't hear anything from you for a while... malloc debugging is useful when you see that heap is corrupted, which is almost always seen immediately at crash time from the stack trace. the problem with heap corruption is that heap is corrupted long before the crash, so you're not able to find the cause of the problem using normal debugging methods. in 'make -j2' case it doesn't look like heap corruption. JK> Incidentally, is it possible to run an application using a cygwin1.dll JK> with malloc debugging but to run gdb on the application using a JK> cygwin1.dll *without* malloc debugging? Gdb seems very difficult to JK> use when malloc debugging is enabled. yes. that's what separate c:\cygdeb\ directory with its own stable non-debugging version of cygwin1.dll is used for. Egor. mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19