features2d's BRISK, ORB and AKAZE break at detectAndCompute() (Bug #4485)

I have to correct myself. KAZE does not work with my setup as well.

I've attached my test code.

#include <opencv2/features2d.hpp>
#include <opencv2/opencv.hpp>
#include <vector>

using namespace cv;

int main(int argc, char** argv)
{
    VideoCapture vid;
    Mat frame;
    vid.open(argv[1]);
    vid.read(frame);

    Ptr<AKAZE> akaze = AKAZE::create();
    Ptr<KAZE> kaze = KAZE::create();
    Ptr<ORB> orb = ORB::create();
    Ptr<BRISK> brisk = BRISK::create();

    std::vector<KeyPoint> akaze_kp, kaze_kp, orb_kp, brisk_kp;
    Mat akaze_desc, kaze_desc, orb_desc, brisk_desc;

    akaze->detectAndCompute(frame, noArray(), akaze_kp, akaze_desc);
    kaze->detectAndCompute(frame, noArray(), kaze_kp, kaze_desc);
    orb->detectAndCompute(frame, noArray(), orb_kp, orb_desc);
    brisk->detectAndCompute(frame, noArray(), brisk_kp, brisk_desc);
}

Unlike in the example code, for every detector I either receive a memory access error / violation or experience a freeze.
Might be a problem on my side. Can anyone confirm sample or example code is running with latest 'master' branch?
Stack trace often ended in ocl related code. Mayber this is related to sync issue (Bug #4380)?

Does it work for you with "cv::ocl::setUseOpenCL(false)" (place it as a first statement in the main)?

Alexander Alekhin wrote:

Does it work for you with "cv::ocl::setUseOpenCL(false)" (place it as a first statement in the main)?

No, sadly it does not.
While running tests with setUseOpenCL(false) I noted a few things:

• If I run my test twice stack traces can look differently (is this an artifact of my debugger? Happened also with active OCL support. I'm using VS2012 by the way.)
• Although every detector I've tested generally tends to run in to memory access violation after a while of calculating.
• AKAZE for example usually gets into trouble after std::vector::_Tidy() method is called leading to a dtor cv::TEvolution::~TEvolution and subsequent failure to deallocate non-existant Mat object in cv::Mat::deallocate()
• KAZE on the other hand usually crashed after a call to cv::Mat::Mat() ctor or while trying to malloc in fastMalloc(...)
• When I turned off OCL support ORB does not crash somewhere along the ocl_HarrisResponses(...) method any more but instead dies at memory write access errors. This happens either before or after (successfully!) selecting features using harris cornerness.
• When I looked at the BRISK detector, I only saw it crashing while trying to push back Keypoints to a std::vector in the BriskScaleSpace::getKeypoints(...) method.

So, what in the name of science is going on here?
Just to make sure, I've compiled the latest master branch on a clean WIN64 system with the same results.
Have you been able to reproduce this Alexander?

I can't reproduce this problem (Linux x64, without OpenCL device):

[1920 x 1080]
922
916
500
545

std::cout << frame.size() << std::endl;

std::cout << akaze_kp.size() << std::endl;
std::cout << kaze_kp.size() << std::endl;
std::cout << orb_kp.size() << std::endl;
std::cout << brisk_kp.size() << std::endl;

Did you cleanup build folder after OpenCV sources update (Did you build from scratch)?