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
vmselect panic caused by query tracer data race #5319
Comments
it was incorrecly captured by goroutine function during for range loop #5319
Thanks for reporting this issue. Currently tracing package is design for single thread usage. But actually, it maybe called concurrently. It causes various data races and those specific panic. I think, it's better to make tracing package thread safe instead of fixing unsafe usage of it at concurrent code. Such as collect results. |
The panic at query tracer should be fixed in the commit 0730c25 . This commit will be included in the next release. |
FYI, the commit has been included in v1.87.11 LTS release. The commit will be included in the new release as well. |
FYI, the bugfix has been included in v1.93.8 LTS release. |
The panic related to enabled query tracing at |
Describe the bug
There is a vm cluster of version
v1.79.6
in our product environment. Thevmselect
component panics every several days.Here are the panic logs
And, below are the args
To Reproduce
It is very hard to reproduce the same problem totally. But we have reproduced similar problem offline with go race detector.
We run
vmselect
with argsand turn on the go race flag.
Here are the data race logs
Version
v1.79.6-cluster
.We run a newer version
v1.93.7-cluster
with-skipSlowReplicas=true
, and met similar problem.Logs
No response
Screenshots
No response
Used command-line flags
No response
Additional information
Most likely related code
The text was updated successfully, but these errors were encountered: