build with latest version of MS Build Tools 2022 (17.10.1) causes call to get_frame() to seg fault

[RussBerg]

This took me a while to figure out but it appears to fail when trying to lock the mutex in start_seq

https://github.com/Photometrics/PyVCAM/blob/9398c286b0cc2c18e77c90b6f48c154b098fb652/src/pyvcam/pvcmodule.cpp#L768

The build of the module all completes and installs without error, it just failed to work.

Downgrading to MS Build Tools 2022 17.2.1 fixes this.

This was tested on a windows 11 machine 64bit, you can download the Build Tools for Spring 2022 LTSC | 17.2 from here https://learn.microsoft.com/en-us/visualstudio/releases/2022/release-history#updating-your-installation-to-a-specific-release

[tomhanak]

I have tried to reproduce the issue with full Visual Studio installation versions 17.9.6 and 17.10.2. Everything seems to work well with Python 3.7 and 3.12.

Could you please provide:

• Minimal code sample? Or did you use one of our tests like tests/seq_mode.py?
• PVCAM version?
• Camera model?

[RussBerg]

• _Minimal code sample? Or did you use one of our tests like tests/seqmode.py? I was testing with single_image_polling.py from tests
• PVCAM version? 2.1.6
• Camera model? Retiga R6

I even tried wiping the computer and starting from scratch and got the same result, the only thing that worked was the different version of build tools.

Other info:

• Python: 3.11
• PVCam Release: 3.10.2-7PMQI
• PVCam SDK: PVCam SDK (for PVCam 3.10.1.1) (I tried every conceivable combination of driver and SDK)

[tomhanak]

Unfortunately, I'm still unable to reproduce the issue even with exactly the same environment and camera you have.

But quick Google query has found that something similar is happening to others: https://stackoverflow.com/a/78599923/6523522

Could you please try the recommended Microsoft solution? I.e. update VCRedist x86 and x64 (Microsoft Visual C++ 2015-2022 Redistributable) to the latest version. Mine is currently 14.40.33810.

[RussBerg]

tried adding the flag D_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR to extra_compile_args in setup.py and that worked 👍 , doesn't quite make sense to me though that you didn't need the flag if using the same build env (14.40.33810)

[RussBerg]

If you add me I can create a PR for the flag addition or you can, the change was

 elif is_windows:
     extra_compile_args = ['-D_DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR']
     include_dirs.append('{}/inc/'.format(pvcam_sdk_path))

[tomhanak]

I'm glad that defining the macro works for you. But as stated by Microsoft in the VS 2022 17.10 STL release notes, that's a workaround only, not the solution:

... You must follow this rule: When you mix binaries built by different supported versions of the toolset, the Redistributable version must be at least as new as the latest toolset used by any app component.

You can define _DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR as an escape hatch.

--- microsoft/STL changelog

Thus we won't apply the proposed patch. It might be reconsidered later when more users report the problem and nothing else helps...

Back to your problem:

• Did you try to update C++ Redistributable?
• Do you run the Python apps on the same computer where you built PyVCAM? (I guess you did not built a wheel for PyVCAM on one PC and did not transfer .whl file to another PC to install it and test there...)
• If you use Python's virtual environment, do you use the same venv for building PyVCAM and running the tests? Can you try to create new clean venv, build PyVCAM and run the test sample?
• Are you sure there isn't older MSVCP140.dll anywhere in the PATH before the system finds the version used to build PyVCAM? (the order of paths in PATH matters...)

[RussBerg]

Thanks for your interest Tom but I can't devote any more time to this problem as the computer in question is being used by others on my team to develop software that uses the camera, so now that I have a work around I/we have to move on.

To answer your questions though:

• Did you try to update C++ Redistributable? yes to 14.40.33810
• Do you run the Python apps on the same computer where you built PyVCAM? Yes
• If you use Python's virtual environment, do you use the same venv for building PyVCAM and running the tests? Yes
• Can you try to create new clean venv, build PyVCAM and run the test sample? Nope, not now anyway maybe down the road when the system is more available
• Are you sure there isn't older MSVCP140.dll anywhere in the PATH before the system finds the version used to build PyVCAM? No Im not sure, I doubt it though because after running into the problem I had the system wiped and OS reinstalled, then built PyVCAM and got the same result