tests: one extra DuckDB handle in the test worker can segfault the suite at teardown (exit 139) #54
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
From the aside in the approving review on #46, plus the flake noted in the approving review on #44.
A probe file that opened a plain
Db(no app, no host) in the same run segfaulted the suite at teardown — exit 139, every test green first — and the failure went away when the file was deleted. So the hazardwithStack's comment documents is broader than "two app stacks": one more DuckDB handle in that worker is enough. Any future test that opens a database directly is a coin flip.Likely related: the #44 review measured the full suite clean on 20 of 21 runs with one unreproducible failure — same rate across two commits, reads as a pre-existing suite flake, and CI has shown the same exit-139-in-teardown shape before.
Worth either serializing DB-opening tests into their own worker, documenting the constraint where a test author will see it, or finding the teardown ordering bug in the DuckDB binding.
Sources: #46 (comment) (aside), #44 (comment) (determinism note).