Compliation test failed on the second one about openeb

[laurentbristiel]

Hello Phil,

did you follow the steps described in "Running the test suite" section? In particular, did you download the dataset archive and extracted it in <OPENEB_SRC_DIR>/datasets?

[sssphil]

Hi @laurentbristiel,

Yes. Now I have the raw files in C:\Users\User\source\repos\openeb\datasets\openeb as well as some tmp_index files and two folders.

[laurentbristiel]

ok, then the problem must come from somewhere else.
For the compilation part, I realize that in the " Running the test suite" section we don't mention this paragraph that is part of the compilation section above:

You can now use OpenEB directly from the build folder. For this, you will need to update your environment variables using this script:
<OPENEB_SRC_DIR>\build\utils\scripts\setup_env.bat

did you perform this action?
If not, it could explain the error you face.

[sssphil]

Hi Laurent,

Thanks for your reply. The error showed up in the tests both before and after I ran the bat file.

I was installing the library to C:\Program Files\Prophesee and changed my Path variables according to the Essentials SDK, but I had to use the camera for another project, so I reverted the installation and reinstalled the Essentials SDK. I configured the project without the pybindings initially:
cmake -A x64 -DCMAKE_TOOLCHAIN_FILE=C:\Users\User\source\repos\openeb\cmake\toolchains\vcpkg.cmake -DVCPKG_DIRECTORY=C:\vcpkg\ -DCOMPILE_PYTHON3_BINDINGS=OFF -DBUILD_TESTING=ON -DCMAKE_INSTALL_PREFIX='C:\Program Files\Prophesee' ..

But today I configured the project using the following command and compiled it again, but the same error showed up when I did the tests (after I ran the setup_env bat file).
cmake -A x64 -DCMAKE_TOOLCHAIN_FILE=C:\Users\User\source\repos\openeb\cmake\toolchains\vcpkg.cmake -DVCPKG_DIRECTORY=C:\vcpkg\ -DBUILD_TESTING=ON ..

I'm using Python3.8.10 and the Python packages have been installed on the PC.

[laurentbristiel]

Hello,
I re-tried the whole compile+test of OpenEB on Windows in both Release and Debug mode and did not run into any problem. I am not exactly in your configuration but quite close. The thing is also that the error message you get is not helping a lot, I don't find any good reference/link that would explain why you get it. I'll keep digging and let you know.

[sssphil]

Hi Laurent,

Sounds good. I also did the same compilation and tests on another Windows PC, and I didn't see that error, but the first and the last tests failed. I'll stay with the Essentials until we find out more info.

Thank you,
Phil

[laurentbristiel]

Ok Phil. Maybe you could elaborate in the initial problem you had with Essentials.You mentioned "I was using the Essentials SDK before but I had some problems with Release/Debug configurations". Could you tell us more? Is there a problem with Essentials we could maybe fix on our side?

[sssphil]

Hi Laurent,

I ran into problems with the start_recording method. It runs well in one build configuration but not the other.

Below is an exception I got while running a modified version of metavision_sdk_get_started.cpp in Debug build. I added a few lines for recording the events. And here is the code sample.txt.

And below is a slightly different exception I got in our project at start_recording, but weirdly, the exception this time was in Release build and the Debug build ran just alright. The method was passed a string of the path to the recording file. (I just noticed it was using the dll with a _d suffix, maybe it was using the wrong dll?)

Thank you,
Phil

[dlzcn]

Hi Phil,

Are you using Visual Studio 2022? Could you please check the "Platform toolset" in your project?
Let's try to set it to 'Visual Studio 2019 V142' and then check whether you still have the unwanted problem.

BRs,
Haifeng

[laurentbristiel]

Hi Phil,

on my side I tried to compile your modifies sample (that you attached earlier in this thread) with the call to cam.start_recording("test");. It worked Ok for me using visual Studio 2019 both in debug and release mode.

Could you check that the folder from where you launch your compiled sample is a writable one? the thing is that when you do cam.start_recording("test");, it will create a test.raw file in the current folder, and it will fail (raise an exception) is this is a read-only folder. And by default this sample is delivered in Program Files/prophesee which is admin-only folder. So when compiling this test you should make a copy of it in a local writable folder (see compilation instruction in the doc)

[sssphil]

Hi @laurentbristiel and @dlzcn,

Thanks for your help. I tested the original sample code (in a CMake project) and it worked in both debug and release mode in Visual Studio 2019. But when I switched back to 2022, it worked in both modes as well this time. I'm trying to figure out if anything happened on the machine recently that made the code work or prevented it from working earlier.

We also have the original sample code in a Visual Studio solution in VS2019, but weirdly, when running in debug mode, the output log shows that the code loads DLLs for the release mode instead, which causes a std::bad_alloc exception at start_recording. I double checked the build mode and made sure it was debug. Do you have any instructions for this case that we could refer to?

As for the second exception I had in the early post, we managed to make it went away by switching the build from "RelWithDebInfo" to "Release". And from the output log, it seems the code now loads the DLLs without the _d suffix. Could you help confirm that is indeed the reason causing the exception?

Thank you and happy hollidays,
Phil

[laurentbristiel]

Hi Phil,

1. With VS2019 in debug mode, I don't reproduce your problem of release DLLs being loaded:
   
   Could you share a screenshot of you VS so that I can see how you detect that the wrong DLL is loaded?

2. About switching from "RelWithDebInfo" to "Release", it seems OK that now you don't load the debug DLLs (ones with the _d) anymore. Though I still don't see how this is related to the exception you are seing...

sorry to not be able to help you more,
Laurent

[sssphil]

Hi Laurent,

Here is what I got:

There are two configurations, Release and Debug, and this is what it says in the configuration manager for the Debug configuration:

And here is the debug log I got from the output window:
metavision_sln_debug_output.txt
The program somehow loaded some packages with both their release and debug DLLs, such as opencv_core.dll and opencv_cored.dll.

In our project, I made two configurations, RelWithDebInfo and Release as shown below, and I can confirm that the RelWithDebInfo config throws at start_recording with Exception thrown at 0x00007FFABE6C9683 (metavision_sdk_driver_d.dll) in k4aviewer.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF., but the Release config runs fine. There are also some differences in the loaded modules (I think the pics have shown all the DLLs loaded from the Essential SDK).

Best,
Phil

[laurentbristiel]

Thanks for all the detailed informations Phil.
I was indeed able to reproduce your problem, but I still don't understand the root cause.
I am going to ask internally to see if we can understand/fix this issue.
Though, currently you are not blocked by this, right?

[sssphil]

Hi Laurent,

Thanks for your message. No, we’re not blocked by this now.

Phil

[laurentbristiel]

Hi Phil,
we found a short-term solution to the problem you raised about RelWithDebInfo configuration.
Our CMake files are indeed not properly handling that case.
So amending the CMake file of a the sample is needed to avoid release/debug DLL confusions.
In the case of sdk_get_started sample, this would give something like:

find_package(MetavisionSDK COMPONENTS core driver REQUIRED)
set_target_properties(MetavisionSDK::base PROPERTIES MAP_IMPORTED_CONFIG_RELWITHDEBINFO RELEASE)
set_target_properties(MetavisionSDK::core PROPERTIES MAP_IMPORTED_CONFIG_RELWITHDEBINFO RELEASE)
set_target_properties(MetavisionSDK::driver PROPERTIES MAP_IMPORTED_CONFIG_RELWITHDEBINFO RELEASE)
set_target_properties(Metavision::HAL PROPERTIES MAP_IMPORTED_CONFIG_RELWITHDEBINFO RELEASE)
set_target_properties(Metavision::HAL_discovery PROPERTIES MAP_IMPORTED_CONFIG_RELWITHDEBINFO RELEASE)
find_package(OpenCV COMPONENTS highgui REQUIRED)
set_target_properties(opencv_core PROPERTIES MAP_IMPORTED_CONFIG_RELWITHDEBINFO RELEASE)
set_target_properties(opencv_imgproc PROPERTIES MAP_IMPORTED_CONFIG_RELWITHDEBINFO RELEASE)
set_target_properties(opencv_highgui PROPERTIES MAP_IMPORTED_CONFIG_RELWITHDEBINFO RELEASE)
set_target_properties(opencv_imgcodecs PROPERTIES MAP_IMPORTED_CONFIG_RELWITHDEBINFO RELEASE)
set_target_properties(opencv_videoio PROPERTIES MAP_IMPORTED_CONFIG_RELWITHDEBINFO RELEASE)

Though this would have to be adapted to each sample.

There is a long term solution that we will try to implement more globally in the project. We are working on it for a future release.