1cacfd1b19
setEnv is not thread safe and could cause a getEnv by another thread to segfault, or perhaps other had behavior. This is particularly a problem when using tasty, because tasty runs the test in a thread, and a getEnv in another thread. The use of top-level TMVars is ugly, but ok because only 1 test actually runs at a time per process. Because it has to chdir into the test repo. The setEnv that remains happens before tasty is running. Sponsored-by: Dartmouth College's Datalad project
22 lines
1.1 KiB
Markdown
22 lines
1.1 KiB
Markdown
The test suite uses setEnv in several places. (No other part of git-annex
|
|
does, basically.) However, setEnv is not thread safe, if another thread
|
|
runs getEnv at the same time it can crash. Or another setEnv, probably.
|
|
|
|
This actually does segfault the test suite runners from time to time.
|
|
The test suite currently notices if there was a segfault and re-runs it.
|
|
While that works well enough, it's always possible there could be some
|
|
other behavior than just a segfault.
|
|
|
|
See <https://gitlab.haskell.org/ghc/ghc/-/issues/21243> for a test case and
|
|
some analysis. See also <https://github.com/UnkindPartition/tasty/issues/326>.
|
|
Tasty uses getEnv, and that can apparently run while a test case is using setEnv.
|
|
|
|
The main places that setEnv is used are in setTestMode. Fixing it will mean
|
|
plumbing a value all through the test suite. Or perhaps, using a single
|
|
toplevel MVar would be ok, since tests don't run concurrently?
|
|
|
|
There is also Utility.Gpg.testHarness, which sets GNUPGHOME. It seems that
|
|
instead, every place that git-annex is run inside the gpg test harness
|
|
would need to add GNUPGHOME to the environment of the git-annex process.
|
|
|
|
> [[fixed|done]] --[[Joey]]
|