comment and open a todo

This commit is contained in:
Joey Hess 2022-05-18 14:57:14 -04:00
parent 969d499a50
commit 6bf09a38ed
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 31 additions and 0 deletions

View file

@ -0,0 +1,11 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2022-05-18T18:05:04Z"
content="""
That test case only runs a few simple git-annex commands, there is not anything
that takes a long time or that can loop.
One possibility is that [[todo/test_suite_unsafe_use_of_setEnv]] could have
led to some undefined behavior that caused it to hang.
"""]]

View file

@ -0,0 +1,20 @@
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.