Algorithm::save (and other Algorithm methods) broken for Java bindings

[westonpace]

I ran into an issue with the Java bindings in OpenCV 3.1

When attempting to save a Boost model I received a core dump.

The error appears to be in the generated Java<->CPP linkage which is:

JNIEXPORT void JNICALL Java_org_opencv_core_Algorithm_save_10
  (JNIEnv* env, jclass , jlong self, jstring filename)
{
    static const char method_name[] = "core::save_10()";
    try {
        LOGD("%s", method_name);
        cv::Algorithm* me = (cv::Algorithm*) self; //TODO: check for NULL                                                                                                                                            
        const char* utf_filename = env->GetStringUTFChars(filename, 0); String n_filename(utf_filename ? utf_filename : "" ); env->ReleaseStringUTFChars(filename, utf_filename);
        me->save( n_filename );
        return;
    } catch(const std::exception &e) {
        throwJavaException(env, &e, method_name);
    } catch (...) {
        throwJavaException(env, 0, method_name);
    }
    return;
}

Debugging the generated core file with gdb it appears that me is not a valid pointer to cv::Algorithm* (although it is not NULL). The line me->save is where the segmentation fault occurs and looking at the stack trace it does not appear that it is getting to the save method.

Calling empty() on StatModel (another class in the heirarchy) does work and I notice the linkage code constructs the pointer as:

    Ptr<cv::ml::StatModel>* me = (Ptr<cv::ml::StatModel>*) self; //TODO: check for NULL                                                                                                                          
    bool _retval_ = (*me)->empty(  );

If I move the save implementation into the StatModel class then it works fine. I tried all other Algorithm implemented methods and got the same results.

[westonpace]

Backtrace from gdb:

#0  0x00007f1498a25cc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007f1498a290d8 in __GI_abort () at abort.c:89
#2  0x00007f1498330795 in os::abort(bool) () from /usr/lib/jvm/java-8-oracle/jre/lib/amd64/server/libjvm.so
#3  0x00007f14984cee23 in VMError::report_and_die() () from /usr/lib/jvm/java-8-oracle/jre/lib/amd64/server/libjvm.so
#4  0x00007f1498335fbf in JVM_handle_linux_signal () from /usr/lib/jvm/java-8-oracle/jre/lib/amd64/server/libjvm.so
#5  0x00007f149832c753 in signalHandler(int, siginfo*, void*) () from /usr/lib/jvm/java-8-oracle/jre/lib/amd64/server/libjvm.so
#6  <signal handler called>
#7  0x00007f14902f5510 in ?? ()
#8  0x00007f1461c928e6 in Java_org_opencv_core_Algorithm_save_10 (env=0x7f149000b1f8, self=139726295094592, filename=0x7f14995ef778) at /home/pace/workspace/opencv-3.1.0/debug/modules/java/core.cpp:4272
#9  0x00007f1481015994 in ?? ()
#10 0x00007f14995ef758 in ?? ()
#11 0x00007f1481015727 in ?? ()
#12 0x00007f14810156e2 in ?? ()
#13 0x00007f14995ef718 in ?? ()
#14 0x00007f1464174728 in ?? ()
#15 0x00007f14995ef788 in ?? ()
#16 0x00007f1464178868 in ?? ()
#17 0x0000000000000000 in ?? ()

[siphomateke]

One year later... Will this be fixed anytime soon? It's pretty crucial to java machine learning.

[mshabunin]

Fixed in #8524