Recent searches
Search options
Last night, I fixed a segmentation fault bug in my #Python testing library time-machine.
There were several outstanding issues about segmentation faults with unclear causes, and I didn’t have time to dive into them.
Then I received a new bug report from Marcin Sulikowski with a minimal reproduction. This research pointed directly at the problem and revealed the other reports as duplicates.
Clear and reproducible bug reports are very valuable contributions!
@adamchainz love this recipe for testing a segfault bug without crashing your test suite! Definitely going to borrow this in the future https://github.com/adamchainz/time-machine/pull/433/files#diff-92ea7165ddf0128246b9758ee9554b3eccb4eceb3d4719bdea9f5495ebbe10a1R477
@adamchainz blogged about it here https://simonwillison.net/2024/Mar/23/test-segfault-in-python/
@simon nice one
@simon @adamchainz, heh, and I would've just used pytest-forked x).
/me hides
@simon @adamchainz This is pretty much the standard method for testing anything that involves a process dying, isn't it? Like, it's used in Googletest and other testing frameworks. Handy to know about for sure, but it's not like it's groundbreaking or anything. (of course it generally doesn't come up in Python testing because Python errors don't kill the whole process unless there's a bug in the interpreter or some native cod involved)
@diazona @adamchainz it was groundbreaking for me!
Really neat idiom, especially the way it uses sys.executable -c to ensure the same Python virtual environment
@simon @adamchainz Ah well, fair enough, I guess I was just taken by surprise to see it described in that way given that I'm so used to seeing it done elsewhere.
Though now that I think about it, the first time I saw the sys.executable thing I did think it was kind of neat too.