Mail Archives: cygwin/2003/12/17/17:14:53
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/
- Raw text -