unexpected exception in jni native method

[nicolas edel]

hi,

i am facing a jvm problem in a program using a jni layer on win2000
plateform.
When an unhandled exception occurs in a native code (outside the jvm),
the jvm generates a hs_err_pidxxxx.log file. This behavior looks fine
since it tells me which native function it has occured in. Indeed i do
not want to handle all signals since some are unrecoverable, and
handling them with C functions wouldn't help me much more...

The problem is that when it occurs, the program then does not exit but
freeze. This make not possible the use of any supervision programm since
the process still looks alive...

Q: what should i do to exit after the error file has been generated
without the need to do it explicitely with the task manager?
(compiling with j2sdk 1.3.1 and VisualC++ 6.0 on win2000)

thanks.

 

[Gordon Beaton]

i am facing a jvm problem in a program using a jni layer on win2000
plateform.

When an unhandled exception occurs in a native code (outside the
jvm), the jvm generates a hs_err_pidxxxx.log file. This behavior
looks fine since it tells me which native function it has occured
in. Indeed i do not want to handle all signals since some are
unrecoverable, and handling them with C functions wouldn't help me
much more...

You seem to imply that this "exception" is similar to Exceptions
thrown in Java. Really this particular exception indicates that you
have a serious coding error in your native code.

My suggestion is that you try to fix the code so that it doesn't
occur, rather than try to deal with the symptom of the hanging
process.

/gordon

 

[nicolas edel]

You seem to imply that this "exception" is similar to Exceptions
thrown in Java. Really this particular exception indicates that you
have a serious coding error in your native code.

My suggestion is that you try to fix the code so that it doesn't
occur, rather than try to deal with the symptom of the hanging
process.

/gordon

well of course the goal and the best solution is to fix all the bugs;
the fact is this unrecoverable exception happens in a module i am not
responsible of and i would like to be able to run the programm before i
can get a fix of this external module.

in a more general way, mechanisms that shows error but blocks the
programm in a unsable sate should be avoided for production softwares, i
think. So waiting for a fix, am i still trying to be able to exit the
programm on error.

nicolas

 

[nicolas edel]

Unless the native code itself is trying to handle the exception
(you don't say anything about what kind of exception you are
getting), this really shouldn't happen. Do you have just in
time debugging set up with Visual C++? If so are you starting
the debugger or is it still up from an earlier instance of the
same error? Under Win2k (or any win32 variant) the JVM should
halt on its on unless prevented from some other source when it
detects a catastrophic error os some kind, like an access
violation in native code.

In any development environment if a program hangs, you have to
use outside tools to kill it. If your native code is causing
a problem, the JVM may act in unpredictable ways. It will try
its best to handle things gracefully, but if it's been stepped
on, it might not be able to anymore. It's up to you to fix
whatever is causing the problem so it doesn't get into this
hung state.

You have to remember, programming in C or C++ is a powerful
and dangerous pastime. It's very easy to shoot yourself in the
foot if you make an error. Once you start stepping on memory
or the stack or doing something else you shouldn't, you're
going to make it extremely difficult to end cleanly. Welcome
to the wild and wooly world of direct access to memory ;-).

--Joe

i have been using c/c++ for many years i you cannot imagine how much i
agree with you about their power but also about how dangerous they are ;-)


i fully agree with anyone claiming the only solution is to have bug-free
code, but the fact is when using third party modules, you sometimes want
to be able to recover disaster, don't you? In this kind of situation,
the solution would be to call the System.exit() method so that the
process could be restarted (then sending a bug report to the concerned
module's developer).
That's the only thing i would like to do, although this is a placebo but
not a solution.


more info the exception i get:
the java program makes use of an external module through a jni layer,
and this module causes the following (disaster...):

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x784ab8f4
Function name=RtlFreeHeap
Library=C:\WINNT\System32\ntdll.dll



nicolas

 

[Joseph Millar]

i fully agree with anyone claiming the only solution is to have bug-free
code, but the fact is when using third party modules, you sometimes want
to be able to recover disaster, don't you? In this kind of situation,
the solution would be to call the System.exit() method so that the
process could be restarted (then sending a bug report to the concerned
module's developer).

In order to do that, the native library you are using has to
have installed something that will catch the access violation.
But the JVM has already done that, that's where the info you're
getting is coming from. And it does exit immediately there
after. But whatever caused this problem has screwed things up.
You see a hang. The JVM tried to do it's thing, but is being
prevented somehow. Error recovery provided by the process code
itself can be fragile and not work if the process has somehow
stepped on things, at that point all bets are off.

My point is this. The JVM would normally exit at this point
(unless stopped by the OS handlers for such things are debugging,
etc), so you mostly likely have one of 2 situations:

1. You or some tool on your system is hooking the OS handler
routines and preventing your process from ending, either
in error or because it was told to. Visual C++ has this
capability, the program is halted and the debugger is
started and attached to the errant process. Most win32
native debuggers have this capability.

2. The process itself is in some sort of hang state due to
its own error. This can be caused by any of a zillion
reasons and the only way to find out is debug it.

That's the only thing i would like to do, although this is a placebo but
not a solution.

To fix the problem, you're going to want to have the jit debugger
stuff turned on and when the trap happens, hit cancel in the
message to launch Visual C++ to see what the stack is like.
If you intend to let someone else find the problem, then you
just need to kill the process. Sure, it would be nice if the
process just ended, but something is broken and you have to
deal with it as is.

more info the exception i get:
the java program makes use of an external module through a jni layer,
and this module causes the following (disaster...):

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x784ab8f4
Function name=RtlFreeHeap
Library=C:\WINNT\System32\ntdll.dll

ntdll.dll is the OS kernel so to speak. RtlFreeHeap is one of the
runtime memory functions, I would expect that it was called with
bad parameters, probably by something in the C Runtime library,
but the only way to find that out is to pop into a debugger and
look at the stack. Since you have been a C programmer for a long
time you recognize that the problem is not actually here, but
further up the call stack, probably originating with a call from
somewhere in your native code which is doing something wrong, like
passing a bad parameter or overwriting some piece of memory. This
is the fun stuff, finding out what went wrong.

--Joe

 

[Gordon Beaton]

i fully agree with anyone claiming the only solution is to have
bug-free code, but the fact is when using third party modules, you
sometimes want to be able to recover disaster, don't you?

Nobody has suggested that you should only release 100% bug free code
(even if that's an admirable goal), but some errors are showstoppers.
I would include anything that can cause the process to hang as
belonging to that category.

Of course it would be nice if it were possible to recover from any
situation, if only to exit gracefully.

But even the most simple error handling mechanism risks failing if
it's in the same process as the errant code, when an error serious
enough to damage the runtme environment itself occurs (e.g. damage to
stack or memory allocation mechanisms).

However you might be able to deal with this using an external
supervisor process and a watchdog timer. The application should notify
the supervisor at regular intervals, and when a notification deadline
is missed, the supervisor can kill and restart the process.

But as I said earlier, I would spend my time trying to find the cause
of the error, rather than try to fix the symptom.

/gordon