Fast winding number terminates with some meshes / segfaults
Hi! I'm using fast_winding_number_for_meshes(v: array, f: array, q: array) Mostly it works, but with some variations of v and f, the code crashes, and gives C++ errors without a clear stack trace. Just
terminate called without an active exception
terminate called recursively
terminate called recursively
[1] 697800 IOT instruction (core dumped)
q is of size 256x256x256x3 The problem is sporadic for different meshes, and haven't found what exactly triggers a crash, just that it's reproducible with the same mesh, and that this error doesn't happen when simplifying the mesh to have less vertices.
using python 3.10, and libigl 2.4.1
Could you please upload the problematic input?
I met the same bugs. Here are the files and codes to reproduce this bug.
data link: https://drive.google.com/file/d/1K7r3udYOXrwn4kmWq--rvDquBkN49sGK/view?usp=sharing
def reproduce_bugs():
m = trimesh.load('Maserati.obj')
nonsurf_points = np.loadtxt('nonsurf_points.xyz')
wn = igl.fast_winding_number_for_meshes(m.vertices, m.faces, nonsurf_points)
Note that the bug occurs occasionally. Every 3 or 4 times I run the program, the bug will occur.
By the way, I find I can reproduce this bug on a Ubuntu 22.04 machine with python 3.10.6, but I can not reproduce it on my windows machine with python 3.10.9
Please try the newest version v2.5.4.dev0 as a lot has changed.
Hi @alecjacobson , I believe this issue is still relevant, I get the same issue with v2.6 on a different mesh.
I've tested it with @guohaoxiang 's data, and it still fails (every run) with v2.6.1:
import trimesh
import numpy as np
import igl
m = trimesh.load('debug_data/Maserati.obj')
nonsurf_points = np.loadtxt('debug_data/nonsurf_points.xyz')
wn = igl.fast_winding_number(m.vertices, m.faces, nonsurf_points)
with
terminate called without an active exception
terminate called recursively
Aborted (core dumped)
with this conda env:
conda list
#
# Name Version Build Channel
_libgcc_mutex 0.1 conda_forge conda-forge
_openmp_mutex 4.5 2_gnu conda-forge
bzip2 1.0.8 hda65f42_8 conda-forge
ca-certificates 2025.11.12 hbd8a1cb_0 conda-forge
icu 75.1 he02047a_0 conda-forge
ld_impl_linux-64 2.44 h1aa0949_5 conda-forge
libblas 3.9.0 38_h4a7cf45_openblas conda-forge
libcblas 3.9.0 38_h0358290_openblas conda-forge
libexpat 2.7.1 hecca717_0 conda-forge
libffi 3.5.2 h9ec8514_0 conda-forge
libgcc 15.2.0 h767d61c_7 conda-forge
libgcc-ng 15.2.0 h69a702a_7 conda-forge
libgfortran 15.2.0 h69a702a_7 conda-forge
libgfortran5 15.2.0 hcd61629_7 conda-forge
libgomp 15.2.0 h767d61c_7 conda-forge
libigl 2.6.1 pypi_0 pypi
liblapack 3.9.0 38_h47877c9_openblas conda-forge
liblzma 5.8.1 hb9d3cd8_2 conda-forge
libnsl 2.0.1 hb9d3cd8_1 conda-forge
libopenblas 0.3.30 pthreads_h94d23a6_3 conda-forge
libsqlite 3.51.0 hee844dc_0 conda-forge
libstdcxx 15.2.0 h8f9b012_7 conda-forge
libstdcxx-ng 15.2.0 h4852527_7 conda-forge
libuuid 2.41.2 he9a06e4_0 conda-forge
libxcrypt 4.4.36 hd590300_1 conda-forge
libzlib 1.3.1 hb9d3cd8_2 conda-forge
ncurses 6.5 h2d0b736_3 conda-forge
numpy 2.3.4 py311h2e04523_0 conda-forge
openssl 3.6.0 h26f9b46_0 conda-forge
pip 25.3 pyh8b19718_0 conda-forge
python 3.11.14 hd63d673_2_cpython conda-forge
python_abi 3.11 8_cp311 conda-forge
readline 8.2 h8c095d6_2 conda-forge
scipy 1.16.3 pypi_0 pypi
setuptools 80.9.0 pyhff2d567_0 conda-forge
tk 8.6.13 noxft_hd72426e_102 conda-forge
trimesh 4.8.3 pyh7b2049a_0 conda-forge
tzdata 2025b h78e105d_0 conda-forge
wheel 0.45.1 pyhd8ed1ab_1 conda-forge
zstd 1.5.7 hb8e6e7a_2 conda-forge
Interestingly, the error occurs on an AMD server ( AMD EPYC 9684X), but it runs fine on apple M4, and Intel (Xeon CPU E5-2650). This is not limited to the python bindings, but also happens on local builds of the c++ igl library.
After seeing the issue https://github.com/libigl/libigl/issues/2412 , and noticing that the crash only occurs on machines with many cores (>128), I figured that it might be related to too many threads started. And indeed, limiting IGL threads with export IGL_NUM_THREADS=32 fixes the problem for me.