libigl-python-bindings icon indicating copy to clipboard operation
libigl-python-bindings copied to clipboard

Fast winding number terminates with some meshes / segfaults

Open mark-at-hypothetic opened this issue 2 years ago • 3 comments

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

mark-at-hypothetic avatar Jun 07 '23 08:06 mark-at-hypothetic

Could you please upload the problematic input?

alecjacobson avatar Jun 07 '23 11:06 alecjacobson

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.

guohaoxiang avatar Sep 10 '24 04:09 guohaoxiang

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

guohaoxiang avatar Sep 10 '24 04:09 guohaoxiang

Please try the newest version v2.5.4.dev0 as a lot has changed.

alecjacobson avatar Feb 02 '25 15:02 alecjacobson

Hi @alecjacobson , I believe this issue is still relevant, I get the same issue with v2.6 on a different mesh.

MariusCausemann avatar Nov 12 '25 23:11 MariusCausemann

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.

MariusCausemann avatar Nov 13 '25 10:11 MariusCausemann

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.

MariusCausemann avatar Nov 13 '25 10:11 MariusCausemann