Avoid NullReferenceExeption in GetTextFromQuery #346
Conversation
In rare cases, a thread-scheduling race condition can cause a thread's state to be ThreadState.Stopped even though it hasn't yet executed its `finally` block, which can result in result.StandardOutput or Error not being assigned a string, leaving them null. Furthermore, the C# docs say not to depend on ThreadState. So instead we check for the thread having ended by seeing whether the `finally` block has assigned a value to its Results property; until then, Results is null. This should guarantee the safety of the existing GetTextFromQuery code, but to be safe we also make sure it can turn null into an empty string.
|
Since this is a race condition, it's rather hard to prove that this fixes the issue. Here are the reproduction steps I used:
On average, running the tests without the bugfix in place produced one failure every 20-30 minutes; in every case, either With the change from this PR in place, I re-ran the same test suite in the same way (running |
Fixes #344.
In rare cases, a thread-scheduling race condition can cause a thread's state to be ThreadState.Stopped even though it hasn't yet executed its
finallyblock, which can result in result.StandardOutput or Error not being assigned a string, leaving them null. Furthermore, the C# docs say not to depend on ThreadState for synchronizing thread activity. So instead we check for the thread having ended by seeing whether thefinallyblock has assigned a value to its Results property; until then, Results is null.This should guarantee the safety of the existing GetTextFromQuery code, but to be safe we also make sure it can turn null into an empty string.
This change is