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: Wed, 17 Dec 2003 17:14:40 -0500 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: Need tips debugging a crash porting an app to cygwin caused by sth overwriting a function Message-ID: <20031217221440.GA7817@redhat.com> Mail-Followup-To: cygwin AT cygwin DOT com References: <3FE0A59A DOT 6060802 AT kaffe DOT org> <20031217213508 DOT GE6296 AT redhat DOT com> <3FE0D154 DOT 4050205 AT kaffe DOT org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FE0D154.4050205@kaffe.org> User-Agent: Mutt/1.4.1i X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com On Wed, Dec 17, 2003 at 10:57:40PM +0100, Dalibor Topic wrote: >Hi Christopher, > >Christopher Faylor wrote: >>On Wed, Dec 17, 2003 at 07:51:06PM +0100, Dalibor Topic wrote: >> >>>I try runing kaffe in gdb in order to run the java compiler, and quite >>>quickly, it crashes, when it enters the findJarFiles function, with a >>>SIGSEGV. The disassembly of the function shows that it's been modified >>>to have a few bad opcodes at the start. >>> >>>Of course, I'd like to know what causes those opcodes to be modified. >>>I've tried watch and awatch findJarFiles, awatch *(long *) findJarFiles, >>>but despite gdb saying that it's setting a hardware watchpoint, I don't >>>get a break in gdb until the function call crashes, which is too late. >>> >>>So I'm wondering what kind of tips experienced Cygwin developers could >>>offer to nail the bug down. >> >>Use 'display' to show the contents of the memory location being modified >>and either single step or use binary search techniques to see when the >>location is modified. >> >>This isn't a cygwin technique. It's just a debugging technique. > >Thanks for the quick, insightful reply. > >I was hoping for some silver bullet, but now it seems like I'll have to >learn to script gdb to do what you propose. Automated debugging, and all >that. I don't see how you could script this. Using a binary search technique it should be possible to narrow this down fairly quickly, assuming that it doesn't take long for the memory to become corrupted. I don't suppose that this is just a variation of something not taking a \r\n ending into account, is it? That's usually solved with the judicious use of O_BINARY or adding a "b" to the appropriate f{re,}open parameter. -- 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/