CadQuery
Segmentation fault upon exiting python on Windows
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.
@mojca Are you able to do the same test with conda to see if there's a segfault?
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).
It seems that installing
cadqueryviacondadoesn'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
cmdeither.The fun part is: I get
Segmentation faultwhen 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.
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.
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).
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.)
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/pythonso 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.
@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.
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).