Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Date: Wed, 17 Dec 2003 16:35:08 -0500 From: Christopher Faylor To: cygwin@cygwin.com Subject: Re: Need tips debugging a crash porting an app to cygwin caused by sth overwriting a function Message-ID: <20031217213508.GE6296@redhat.com> Mail-Followup-To: cygwin@cygwin.com References: <3FE0A59A.6060802@kaffe.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FE0A59A.6060802@kaffe.org> User-Agent: Mutt/1.4.1i X-IsSubscribed: yes Reply-To: cygwin@cygwin.com 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. -- 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/