Re: RFR (M) 8224079: ExceptionJniWrapper for the Strace test suite

Fri, 17 May 2019 11:45:19 -0700

Hi JC,

I guess this code is a bit different in that it expects to see some errors and has code to specifically deal with them. What is  your plan on updating the callers of this method:

                case ThreadController.NATIVE_TYPE:
                    result = recursionNative(depth, 0, false);

                    if (result == 1) {
                        log.display("Fatal error (OutOfMemoryError or "
                                + "StackOverflow) is thrown in native method of "
                                + " thread " + num);
                        return;
                    } else if (result == 2) {
                        log.complain("Unexpected exception is thrown in native "
                                + "method of thread " + num);
                        strace001.testFailed = true;
                        return;
                    }
                    break;

Won't your changes result in the exception being propagated rather then returning a 1 or a 2?

Chris

On 5/16/19 3:56 PM, Jean Christophe Beyler wrote:
Hi all,

I was wanting to continue on deploying the ExceptionJniWrapper and the first on the list was this one C++ file. It is used by various Strace tests and I thought I'd stop at just this one to make it easier for reviewing.


The biggest thing to note is that the error messages change a bit, originally if the native code noticed a problem it would return either 1 or 2, providing a message in Java land:

    a return of 1 would provide a message containing (OutOfMemoryError or StackOverflow) 
    a return of 2 would provide a generic message such as  Unexpected exception...

Now 1 would give just a generic internal error but it would be with a message such as:
FATAL ERROR in native method: JNI method CallIntMethod : internal error from StackTraceController.cpp : 48
at nsk.monitoring.stress.thread.RunningThread.recursionNative(Native Method)
at nsk.monitoring.stress.thread.RunningThread.recursionJava(strace001.java:343)
at nsk.monitoring.stress.thread.RunningThread.recursionNative(Native Method)
at nsk.monitoring.stress.thread.RunningThread.recursionJava(strace001.java:343)
at nsk.monitoring.stress.thread.RunningThread.recursionNative(Native Method)
at nsk.monitoring.stress.thread.RunningThread.recursionJava(strace001.java:343)
at nsk.monitoring.stress.thread.RunningThread.recursionNative(Native Method)
at nsk.monitoring.stress.thread.RunningThread.recursionJava(strace001.java:343)
at nsk.monitoring.stress.thread.RunningThread.recursionNative(Native Method)
at nsk.monitoring.stress.thread.RunningThread.recursionJava(strace001.java:343)
at nsk.monitoring.stress.thread.RunningThread.recursionNative(Native Method)
at nsk.monitoring.stress.thread.RunningThread.recursionJava(strace001.java:343)
at nsk.monitoring.stress.thread.RunningThread.recursionNative(Native Method)
....

and you would guess it is either an OOM or a stack overflow. And 2 actually now gives you which method failed. So it's a win for the 2 case, for the 1 there is an extra step that, for me, seemed relatively straight forward.

I can change the code slightly for the 1 case to make the error message more specific and closer to the original but I was not sure it was worth it.... What do you all think?

Thanks for your help,
Jc


Reply via email to