Segmentation fault upon exiting python on Windows

[mojca]

To Reproduce

import cadquery

$ python
Python 3.12.8 (tags/v3.12.8:2dc476b, Dec  3 2024, 19:30:04) [MSC v.1942 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import cadquery
>>> print('Hello')
Hello
>>> quit()
Segmentation fault
(venv2)

If I comment out

from .assembly import Assembly, Color, Constraint

from __init__.py, it no longer crashes.

Environment

OS: Windows 11, Python 3.12.8 (installed by the official Python installer), running from Mingw64 shell.

Was CadQuery installed using Conda?: No, via pip install cadquery

Output of pip list:

$ pip list
Package           Version
----------------- -------------
aiohappyeyeballs  2.6.1
aiohttp           3.13.0
aiosignal         1.4.0
attrs             25.4.0
cadquery          2.6.0
cadquery-ocp      7.8.1.1.post1
casadi            3.7.2
contourpy         1.3.3
cycler            0.12.1
ezdxf             1.4.2
fonttools         4.60.1
frozenlist        1.8.0
idna              3.10
kiwisolver        1.4.9
matplotlib        3.10.6
more-itertools    10.8.0
msgpack           1.1.1
multidict         6.7.0
multimethod       1.12
nlopt             2.9.1
numpy             2.3.3
packaging         25.0
path              17.1.1
pillow            11.3.0
pip               24.3.1
propcache         0.4.0
pyparsing         3.2.5
python-dateutil   2.9.0.post0
PyYAML            6.0.3
six               1.17.0
trame             3.12.0
trame-client      3.11.1
trame-common      1.0.1
trame-server      3.6.3
trame-vtk         2.10.0
typing_extensions 4.15.0
typish            1.9.3
vtk               9.3.1
wslink            2.4.0
yarl              1.22.0

Using: python from mingw64 shell:

$ which python
/c/Program Files/Python/Python312/python

If I run the same Python and same venv from cmd, I don't see the Segmentation Fault printed out.

[jmwright]

@mojca Are you able to do the same test with conda to see if there's a segfault?

[jmwright]

@mojca Are you able to use pdb to see if it gives any insight?

[lorenzncode]

I cannot reproduce it with 2.6.0 installed with conda (micromamba).

[mojca]

It seems that installing cadquery via conda doesn't reproduce the crash. (Why is it so non-obvious to enable it inside bash/msys?)

That said, I also don't fully understand what's going on behind the scenes when activating it inside msys (or more precisely: I usually run "git bash"). The version from pip doesn't crash in cmd either.

The fun part is: I get Segmentation fault when running

import cadquery

but no segmentation fault with

import pdb
import cadquery

Off-topic: A few days ago I was staring at some (totally unrelated) code that was using python bindings in the background. The code failed to release an object: the object reference count apparently kept being positive and thus the object failed to disconnect from the server (which should have happened automatically upon deletion). It turned out that the code worked as expected when it wasn't run from Visual Studio Code with debugger. It looks like VS Code's debugger kept an unwanted reference to that object.

This looks like a very similar case, only inverse (the debugger keeps a reference to an object and prevents a crash). It does seem to me like some wrong dereferencing in python when destroying objects at the end of the run, though this is still a pure speculation.

Either way I'm not sure how to actually debug with pdb when it only crashes at the very very very end (when objects are already being destroyed).

[adam-urbanczyk]

It seems that installing cadquery via conda doesn't reproduce the crash. (Why is it so non-obvious to enable it inside bash/msys?)

That said, I also don't fully understand what's going on behind the scenes when activating it inside msys (or more precisely: I usually run "git bash"). The version from pip doesn't crash in cmd either.

The fun part is: I get Segmentation fault when running

Not sure what do you mean here. Are you in the end getting a segfault with conda or not?

Second question, are you getting a segfault with pip and without using msys at all?

You already answered this in your bug report.

Either way I'm not sure how to actually debug with pdb when it only crashes at the very very very end (when objects are already being destroyed).

I think it was supposed to be gdb not pdb. I.e. it might be useful to get an actual backtrace.

[adam-urbanczyk]

OK, AFAICT this looks like an ABI issue. I assume that windows wheel are in general built with MSVC. If you want to use MSYS, you should probably rebuild all the dependencies with the correct toolchain.

[mojca]

OK, AFAICT this looks like an ABI issue. I assume that windows wheel are in general built with MSVC. If you want to use MSYS, you should probably rebuild all the dependencies with the correct toolchain.

To clarify. I'm using the "original" python:

$ which python
/c/Program Files/Python/Python312/python

so I fail to see how this would play a role. I assume that both python and packages were build with MSVC.

I only use "git bash" (stripped down version of msys) because I need to be able to process bash scripts (and also because I feel more comfortable using basic unix commands rather than the ancient cmd).

[mojca]

Not sure what do you mean here. Are you in the end getting a segfault with conda or not?

No, with conda I don't get it.

I think it was supposed to be gdb not pdb. I.e. it might be useful to get an actual backtrace.

If it was meant to be gdb, let me first figure out how to set it up. (I installed the full msys2 now, but I probably need to set up paths to see Python from Windows.)

[adam-urbanczyk]

IDK your setup, but if you have gdb simply attach it to a running process. No PATH(s) involved AFAIK.

To clarify. I'm using the "original" python:

$ which python
/c/Program Files/Python/Python312/python

so I fail to see how this would play a role. I assume that both python and packages were build with MSVC.

The hypothesis is that your env is causing a different/wrong version of some shared library being loaded.

[dattasid]

@mojca Does cadquery on cmd take a long time to exit ?

I see the SEGV on msys, and also the program exits after a long delay on cmd. Which tells me the SEGV might be happening but is hidden.

[mojca]

The import cadquery needed 13 seconds in my first attempt (and cca. 2 seconds in the second attempt). The exit() needs about 3 seconds. I cannot judge whether that's long (without importing cadquery first it's instant). Under git bash the exit takes less than one seconds with cadquery and also segfaults fast ;)

I don't have enough experience to be able to judge whether exit time has anything to do with a hidden segfault (but it could of course be that it segfaults without being explicit about it).

[69k9zb628r-sys]

I hit this on a clean Windows 11 / python.org CPython 3.12.14 install and traced it to the mechanism. Three findings that change the picture in this thread:

1. It is not the shell. No MSYS and no CadQuery needed — it is the pair of dependencies:

> python -c "import casadi, nlopt"    # exit -1073741819 (0xC0000005), sometimes 0xC0000374, after all output
> python -c "import casadi"           # exit 0
> python -c "import nlopt"            # exit 0

Same from native PowerShell ($LASTEXITCODE = -1073741819) and from cmd.exe. In cmd it only looks clean: a %ERRORLEVEL% on the same line as the command expands before the command runs, so it prints the previous value. With delayed expansion (cmd /v:on /c "python -c ""import casadi, nlopt"" & echo !ERRORLEVEL!") cmd reports the same -1073741819. Import order does not matter, and -X faulthandler shows Windows fatal exception: access violation with <no Python frame> — native, during interpreter teardown. That also explains @dattasid's slow exit on cmd.

2. Different C runtimes. From the import tables (casadi==3.8.0, nlopt==2.11.0, both from PyPI):

wheel	runtime it links
nlopt/_nlopt.pyd, nloptjni.dll	MSVCP140.dll, VCRUNTIME140.dll, api-ms-win-crt-* (MSVC / UCRT)
casadi/_casadi.pyd, libcasadi.dll	libgcc_s_seh-1.dll, libstdc++-6.dll, libwinpthread-1.dll, msvcrt.dll (MinGW-w64, legacy CRT), bundled in the wheel

This is @adam-urbanczyk's ABI hypothesis, confirmed — but caused by the wheels, not by the user's environment. conda builds everything with one toolchain, hence no repro for @lorenzncode.

3. The exact mechanism is SWIG's shared runtime. Loading any of casadi's DLLs next to nlopt with ctypes does not crash; only the two Python extension modules together do. Both are SWIG modules and both embed swig_runtime_data5, so they share SWIG's runtime type table through the swig_runtime_data5.type_pointer_capsule capsule. At exit the capsule's destructor walks the shared table and frees every module's type records with the C runtime of whichever module created the capsule — memory the other runtime allocated. Proof: clearing the destructor before exit makes the pair exit 0:

import sys, ctypes, casadi, nlopt
cap = sys.modules["swig_runtime_data5"].type_pointer_capsule
ctypes.pythonapi.PyCapsule_SetDestructor.argtypes = [ctypes.py_object, ctypes.c_void_p]
ctypes.pythonapi.PyCapsule_SetDestructor(cap, None)   # exit 0; without this line: 0xC0000005

Fix: #2092 does two things, as separate commits: (1) imports casadi and nlopt inside the functions that use them, so import cadquery loads neither (__init__ → assembly → occ_impl.solver → casadi; __init__ → sketch → occ_impl.sketch_solver → nlopt); (2) registers an atexit handler that clears that capsule destructor when both are loaded, so Assembly.solve()/Sketch.solve() on Windows no longer crash at exit either — the handful of records are leaked at exit instead of freed across runtimes. With both, tests/test_assembly.py + tests/test_sketch.py pass (196) and the pytest process exits 0, where it exited 0xC0000005 before.

The durable fix is upstream of CadQuery — SWIG's SWIG_Python_DestroyModule assumes one allocator per process, and casadi's Windows wheels are the outlier (MinGW on legacy msvcrt); I can file those separately if useful.