Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <3FE0DB67.8090009@kaffe.org>
Date: Wed, 17 Dec 2003 23:40:39 +0100
From: Dalibor Topic <robilad AT kaffe DOT org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Need tips debugging a crash porting an app to cygwin caused by sth overwriting a function
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>
In-Reply-To: <20031217221440.GA7817@redhat.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS perl-11
X-IsSubscribed: yes

Hi Christopher,

Christopher Faylor wrote:
> 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 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 ;)

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.

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

Thanks for the tip. All calls to f{re,}open in the VM core use O_BINARY.

cheers,
dalibor topic


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