git-annex/doc/todo/test_suite_unsafe_use_of_setEnv.mdwn

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]]
comment and open a todo 2022-05-18 18:57:14 +00:00			`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.`
avoid setEnv while testing gpg setEnv is not thread safe and could cause a getEnv by another thread to segfault, or perhaps other had behavior. Sponsored-by: Dartmouth College's Datalad project 2022-05-18 19:32:40 +00:00
avoid setEnv in test framework when tasty is running 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 2022-05-18 20:41:41 +00:00			`> [[fixed\|done]] --[[Joey]]`