Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Wed, 17 Dec 2003 17:50:50 -0500
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
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: <20031217225050.GA8372@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> <20031217221440 DOT GA7817 AT redhat DOT com> <3FE0DB67 DOT 8090009 AT kaffe DOT org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3FE0DB67.8090009@kaffe.org>
User-Agent: Mutt/1.4.1i
Reply-To: cygwin AT cygwin DOT com

On Wed, Dec 17, 2003 at 11:40:39PM +0100, Dalibor Topic wrote:
>I was thinking about defining a gdb command along the lines of
>
>define my-stepi-watch
>while (*(long *) findJarFiles == original_value)
>stepi
>end
>
>though I've never done that before, so I'm not sure if that would work ;)

It might work but I think you'd probably end up tracking the heat death
of the universe before you'd see a result.  :-)

>I'm not sure about using binary search, as there might be some threading 
>involved, so I assume it's safer to just check on each stepi and let the 
>machine run overnight.

Ah, threading.  That complicates matters a lot.

Another way to catch this is to call VirtualProtect on the regions in
question and make them read-only.  Then when something trashes the
location it will die immediately.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base/virtualprotect.asp

cgf

--
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/