-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
openmp and per_face_normals pybind11 wrapper crash #193
Comments
You can always set the Environment variable to True like it suggested and see if it might fix the problem or just in the terminal you are running this |
yes, thank you so much I was about to write that my problem was that I set it in the cmakelists.txt which is the wrong scope. |
Unfortunately the problem still exists, I switched to a different mesh lock_input_tri_g3.obj (added in the repository under example data folder) and the crash is "segmentation fault: 11", no comprehensible message. This only happens when opemp is used. When I remove openmp from the cmakelists it works fine. It also works with openmp in cpp without any crashes or flag settings. I have a Mac OS** |
libigl shouldn't be using any openmp. #243 is switching to nanobind. Feel free to open with more information after that change. |
Hi,
I'm actually wrapping my cpp code with libigl to python using pybind11 and I figured out that it crashes when I use openmp on per_face_normals. Without openmp in cmakelists everything works fine.
Did you have any issues like that with pybind11 and openmp? Would really appreciate any advice.
Here is the minimal repository for problem reproduction:
https://github.com/stigersh/MinimalBindIGL
it has 2 methods wrappers of igl - doubleArea which works fine and per_face_normals which crashes the python kernel (testClass.py). There is also a main indicating none of them crash as a cpp project.
crash message:
OMP: Error #15: Initializing libomp.dylib, but found libomp.dylib already initialized.
OMP: Hint This means that multiple copies of the OpenMP runtime have been linked into the program. That is dangerous, since it can degrade performance or cause incorrect results. The best thing to do is to ensure that only a single OpenMP runtime is linked into the process, e.g. by avoiding static linking of the OpenMP runtime in any library. As an unsafe, unsupported, undocumented workaround you can set the environment variable KMP_DUPLICATE_LIB_OK=TRUE to allow the program to continue to execute, but that may cause crashes or silently produce incorrect results. For more information, please see http://openmp.llvm.org/
**setting the KMP_DUPLICATE_LIB_OK to TRUE didn't help as well.
Thanks a lot!
The text was updated successfully, but these errors were encountered: