cv::aruco::detectMarkers crashes on AMD processors.

[antithing]

System information (version)

OpenCV => 4.1
Operating System / Platform => Windows 64 Bit
Compiler => Visual Studio 2019

Detailed description

I have a function in my application that uses opencv and the cv::aruco module.

On machines with Intel cpus, it runs great. (tested on more than 20 PCs). On machines with AMD cpus (tested on two), it freezes and crashes the application. The only difference on the testing machines is the processor.

The crash occurs at this function:

cv::aruco::detectMarkers(InImage, dictionary5, corners, ids, detectorParams5, rejected);
I have tried rebuilding opencv and disabling AVX512 instructions in OpenCVCompilerOptimizations.cmake, and I see the same thing.

How can i solve this issue?

Steps to reproduce

Build opencv from source (4.11). Run the function cv::aruco::detectMarkers on a PC with an AMD threadripper Ryzen processor.

[alalek]

How can i solve this issue?

Detect root cause of this issue first:

• build in debug mode (or release with debug information through -DBUILD_WITH_DEBUG_INFO=ON)
• run under debugger
• and investigate.

Capture stack traces of crash / hang points at least.

Try to play with number of threads.

---

4.1

Outdated versions are not supported. Try to check the latest code from master branch.

[antithing]

Hi @alalek, thanks for getting back to me. I cannot run in debug mode, as I do not have access to an AMD processor to use. On all our Intel based machines there is no problem.

As soon as our client runs the function on an AMD machine, it freezes. (the only difference in machines is the processor). We have tracked it down to the 'detectMarkers' function for sure, and I am having trouble debugging further then that remotely!

Changing the cornerRefinementMethod has no effect.
Passing in an image that works perfectly on the Intel machine will crash the AMD, so it is not to do with the input data.

Where can I play with number of threads? Is this a variable somewhere?
What else might i look at here?

Thanks again!

[alalek]

• API: cv::setNumThreads()
• Environment variable: OPENCV_FOR_THREADS_NUM=N

---

I don't have access to mentioned configuration too.
Probably somebody from community with AMD configuration may take a look on this, but they need complete minimal reproducer (with all input data for crashed call, can be captured through cv::FileStorage before invocation)

[antithing]

I can confirm that using cv::setNumThreads(1) has fixed this issue. As to why it was happening, i am still not sure....

[AleksandrPanov]

My configuration is Ryzen 2700x (8 cores, 16 threads), Ubutu 20.04. I have successfully run tests with any number of threads (this PR #3151).

• Try using the new version of OpenCV
• Have you tried running the code on non-windows?

[AleksandrPanov]

checked on Win10 PC with Ryzen 4600h, base ArUco tests successfully done

Perhaps, your problem is related to this: #2738

The new version of OpenCV avoids this problem.