This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Need tips debugging a crash porting an app to cygwin caused by sth overwriting a function

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)

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

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

dalibor topic

-- Unsubscribe info: Problem reports: Documentation: FAQ:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]