Tracking Bugs In Native Code

[cppaddict]

I have a Java app which which makes frequent use native calls. The app
runs fine for about 5-10 minutes, and then crashes with the error
below, which may or may not be caused by the native code. No error
report is created, so my question is: Does anyone have advice on how I
can go about tracking down the error. As you can see, the error
message is scant on additional information.

Thanks for any ideas,
cpp

----ERROR MESSAGE FOLLOWS----

****************
Another exception has been detected while we were handling last error.
Dumping information about last error:
ERROR REPORT FILE = (N/A)
PC = 0x02c90cc3
SIGNAL = -1073741819
FUNCTION NAME = (N/A)
OFFSET = 0xFFFFFFFF
LIBRARY NAME = (N/A)
Please check ERROR REPORT FILE for further information, if there is
any.
Good bye.

 

[Sudsy]

cppaddict wrote:

Thanks for any ideas,
cpp

----ERROR MESSAGE FOLLOWS----

****************
Another exception has been detected while we were handling last error.
Dumping information about last error:
ERROR REPORT FILE = (N/A)
PC = 0x02c90cc3
SIGNAL = -1073741819
FUNCTION NAME = (N/A)
OFFSET = 0xFFFFFFFF

<snip>

First guess would be stack corruption as the values don't make any
sense. As to cause, most likely something like specifying an array
of fixed dimension in the function and then exceeding the bounds.
That could, to use the vernacular, "blow the stack" and all the
normal values which would be contained therein, including the
return address, etc.
Take a look at the signal and offset: no resemblance to anything
sane. Overwrite the return address and you'll end up throwing an
illegal memory access (SIGSEGV).
Send code and money and I could sort this out for you...?

 

[Chris Uppal]

Does anyone have advice on how I
can go about tracking down the error.

*Masses* of logging (~ 1 log statement per line -- automate it if you can).

Remove or dummy-out stuff until it works, then put stuff back until it breaks
(use a binary-chop style approach).

Pay Sudsy ;-)

Basically, good old-fashioned grind. You are lucky that it fails so quickly,
it shouldn't take more than a few days (maybe less !) to track down if you work
at it.

-- chris

 

[cppaddict]

*Masses* of logging (~ 1 log statement per line -- automate it if you can).

Chris,

What is the right way to do logging? I have been using println()
statements at various break points to do debugging.... I know there's
probably a better way.

Thanks,
cpp

 

[Chris Uppal]

What is the right way to do logging? I have been using println()
statements at various break points to do debugging.... I know there's
probably a better way.

Well, that's what I'd probably do too. Maybe use some sort of script to add
println()s semi-automatically (get the script to do most of the work and then
clean up by hand).

There are undoubtedly better ways to do this in both C[++] and Java, but I
don't know of any that works for both, and in any case, I tend to prefer
low-tech solutions in situations like this -- there's less chance of something
"clever" disturbing the bug your trying to find.

Not much help, I'm afraid. Unless you get an inspiration, you are in for some
tedious work.

-- chris

 

[Michael Borgwardt]

Chris,

What is the right way to do logging? I have been using println()
statements at various break points to do debugging.... I know there's
probably a better way.

System.out.println() is fine for developer tests. More sophisticated methods
are called for if you want to be able to do after-the-fact analysis of problems
that occurred in production and may not be easily reproducable.

There is a number of logging APIs for this purpose, most notably
java.util.logging since Java 1.4. These allow you to configure logging
granularity and do just about anything imaginable with the output.