Fix ConflatedBroadcastChannelLincheckTest in kotlinx.coroutines #273
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ndkoval
changed the title
ndkoval
force-pushed
the
fix-coroutines-build
branch
3 times, most recently
from
7ec930a to
b17c09b
Compare
…s that should be loaded by the system class loader
ndkoval
force-pushed
the
fix-coroutines-build
branch
from
71eb2f1 to
08f9877
Compare
eupp
reviewed
Feb 19, 2024
| setResult(iThread, Done) | ||
| } | ||
| } | ||
|
|
||
| fun waitUntilAllThreadsFinishTheCurrentTasks() { |
There was a problem hiding this comment.
Maybe just awaitAllThreads or awaitAllTasks ?
There was a problem hiding this comment.
Actually, we do not need this function at all -- the code always waits for all tasks to be completed. I've checked that we never call Thread.yield() in the implementation.
| @@ -283,8 +284,11 @@ abstract class ManagedStrategy( | |||
| * @param codeLocation the byte-code location identifier of the point in code. | |||
| */ | |||
| private fun newSwitchPoint(iThread: Int, codeLocation: Int, tracePoint: TracePoint?) { | |||
| if (!isTestThread(iThread)) return // can switch only test threads | |||
| if (!isTestThread(iThread)) return | |||
There was a problem hiding this comment.
Isn't this check is duplicated by the inIgnoredSection(iThread) check on the next line?
There was a problem hiding this comment.
Let's fix that under #276 -- there are many such cases.
|
This issue was quite a journey. Thanks to @eupp for the help with the investigation and the review! |
eupp
approved these changes
Feb 19, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes failing ConflatedBroadcastChannelLincheckTest; see the build below
https://teamcity.jetbrains.com/buildConfiguration/KotlinTools_KotlinxLincheck_IntegrationTestWithKotlinxCoroutinesDevelopLinuxOnJava17/4485333?hideTestsFromDependencies=false&hideProblemsFromDependencies=false&expandBuildDeploymentsSection=false&expandBuildTestsSection=true&expandBuildProblemsSection=true
Investigation
There were two issues.
Solution: ignore the corresponding classes in
doNotTransform(..).suddenInvocationResultinManagedStrategywas set to a non-null value. After that, all furtherinIgnoredSection(..)calls returnedtrue(it checked forsuddenInvocationResultbeing non-null, I don't know why), making it impossible for other threads to notice the spin-lock detection and also finish. This resulted in an infinite spin-lock and deadlock detection. However, the latter was ignored, assuddenInvocationResultwas non-null. Notably, the "hanging" thread was still callingnewSwitchPoint(..)periodically (there was a veeery long spin-lock). Then, after starting the next interleaving, thesuddenInvocationResultfield was reset tonull, and the hanging threads, that were callingnewSwitchPoint(..)periodically, published events related to the previous interleaving. This caused non-deterministic behavior in the model checker.Solution: check whether
suddenInvocationResultis non-null in the beginning of the analysis, removing the corresponding check frominIgnoredSection(..).