Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upCrash on startup due to unguarded concurrent map writes in discovery.go #2444
Comments
gouthamve
referenced this issue
Mar 6, 2017
Merged
Fix Map Race by Moving Locking closer to the Write #2476
fabxc
closed this
in
#2476
Apr 7, 2017
This comment has been minimized.
This comment has been minimized.
lock
bot
commented
Mar 23, 2019
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
lock
bot
locked and limited conversation to collaborators
Mar 23, 2019
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
gottwald commentedFeb 23, 2017
What did you do?
Start prometheus
What did you expect to see?
A normal start
What did you see instead? Under which circumstances?
A crash
Environment
GCE instance with prometheus running inside of a container
System information:
Linux 4.4.0-63-generic x86_64
Prometheus version:
prometheus, version 1.5.2 (branch: master, revision: bd1182d)
build user: root@1a01c5f68840
build date: 20170210-16:23:28
go version: go1.7.5
Prometheus configuration file:
Sorry. Not sure if I can disclose it here. But won't be needed for debugging.
Logs:
AFAICS in the current release-1.5 branch, this is caused by an unguarded write to the target groups map invoked here:
prometheus/discovery/discovery.go
Line 255 in bd1182d
And finally done here:
prometheus/discovery/discovery.go
Line 310 in bd1182d
Sadly the comments in the TargetSet struct definition don't state what the mutex guards (only the map vs. the whole struct).
If it only guards the map, it would be possible to move the locking closer to the actual map write inside of
TargetSet.setTargetGroupinstead of doing it before all invocations ofTargetSet.setTargetGroup. Probably would make it easier for the caller.The bug also exists in the master branch.