5 ms·
A notable downside that is not mentioned: the Python interpreter is far from Valgrind-clean. Valgrind is generally a powerful tool for debugging memory errors,
by haberman 5y ago
A notable downside that is not mentioned: the Python interpreter is far from Valgrind-clean. Valgrind is generally a powerful tool for debugging memory errors, but if you wrap your C code in Python, Valgrind will be so noisy as to be ineffective. Python startup is also very heavyweight; combined with the ~60x slowdown from Valgrind this is something you are going to notice.
The Python interpreter does not even use malloc()/free() directly by default; it layers its own memory allocator on top called PyMalloc (https://docs.python.org/3/c-api/memory.html#pymalloc https://docs.python.org/3/c-api/memory.html#pymalloc). You can disable this by setting an environment variable (PYTHONMALLOC=malloc), but even then you will see many Valgrind warnings inside the Python interpreter itself.
- p403n1x87 5y agoThat's a good argument for keeping these kind of tests separate. Indeed Austin has dedicated Valgrind integration tests just for this reason.
- wiredfool 5y agoI’ve had success running valgrind on python code with a very small suppression list to cover all of the python interpreter issues (at least for safety, not leaks) and let me focus on the code.
- cozzyd 5y agoIs such a suppression list publicly available somewhere?
- wiredfool 5y agohttps://github.com/python-pillow/docker-images/blob/main/ubuntu-20.04-focal-amd64-valgrind/python.supp https://github.com/python-pillow/docker-images/blob/main/ubu... This docker image is what we’re using in CI to do memory safety checks against the pillow c extension.
- cozzyd 5y agoThat is indeed very short! Thanks!