-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deadlock one single iteration test #1253
Comments
Any idea why don't we use func (m *RootModule) NewModuleInstance(vu k6modules.VU) k6modules.Instance {
// ...
browserRegistry: newBrowserRegistry(
context.Background(), // why isn't this vu.Context()?
... When I looked into this stack trace (of test run ID 2591015), it's clear that
Even if we use VU context, why would k6-core cancel the context is another question, though.... But it might still be better than getting nothing out of the errors. At least, we can log something when the context is canceled due to timeout, etc. These components (session and event loop) are suspicious because there are no other goroutines left but them. There is probably some bug in them. They probably both want to receive it, but nobody sends something to the channels they listen to. Maybe we can build some circuitry in the module so that when all subcomponents finish, we can stop running these two. |
Here's the reason why we're using a background context. I still need to take a deep dive into your findings though to align properly. Thanks for investigating @inancgumus! |
Yep, I agree with the idea of building something in that can force close any remaining goroutines. Maybe, If a goroutine isn't listening to a context, it could register itself to a global The |
I found a stack trace which might be useful in helping to diagnose the issue or at least use a symptom to link failures to this issue:
|
Happened again: 2840522 |
Test run: 2568554, 2571988 and 2591015, 2840522.
The text was updated successfully, but these errors were encountered: