41–44 of 44 posts
Earlier quoted context omitted.
I’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.
Is such a suppression list publicly available somewhere?
This docker image is what we’re using in CI to do memory safety checks against the pillow c extension.
Earlier quoted context omitted.
Is such a suppression list publicly available somewhere?
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.
Earlier quoted context omitted.
Nice. Now how could I get this to work on a small embedded device compiker (gbdk using lcc), which likely doesn't have that constructor attitude.
One approach is to build test traversal machinery out of function static variables and have every TEST() macro turn into a function that takes a pointer to some state controlling which test to run next. You don't need malloc if using local variables either, which is helpful when your target doesn't have malloc or when debugging memory problems on targets that do. It's nice to know the test framework cannot be leaking…
Earlier quoted context omitted.
One approach is to build test traversal machinery out of function static variables and have every TEST() macro turn into a function that takes a pointer to some state controlling which test to run next. You don't need malloc if using local variables either, which is helpful when your target doesn't have malloc or when debugging memory problems on targets that do. It's nice to know the test framework cannot be leaking…
Interesting. But how would one test "know" about the next one, especially if they are in different compilation units.