concurrent map read and map write #5733
Comments
|
Thanks for reporting this @mrwilby! This is definitely a core bug - potentially introduced when |
The graph walker holds a lock that's passed down to BuiltinEvalContext and guards access to interpolation variables as they're written using SetVariables. The likely problem being expressed in #5733 is that the same map reference is also passed down to the Interpolater.Variables field, which is used for variable lookup. Here, we plumb the same lock we're using to guard access for writes down and acquire it before doing variable reads as well. It's not as fine grained as perhaps it could be, but all the context tests pass and I believe this should address #5733.
The ContextGraphWalker struct includes a lock that's passed down to BuiltinEvalContext and guards access to interpolation variables as they're written using SetVariables. The likely problem being expressed in #5733 is that the same map reference is also passed down to the Interpolater.Variables field, which is used for variable lookup. Here, we plumb the same lock we're using to guard access for writes down and acquire it before doing variable reads as well. It's not as fine grained as perhaps it could be, but all the context tests pass and I believe this should address #5733.
|
experienced the same problem - 0.6.14 seems to fix it. thank you! |
|
That's great news @roderickrandolph! #5772 did land in 0.6.14 and attempts to address this - @mrwilby can you give 0.6.14 a shot as well and let me know if it sorts out your issue? |
The ContextGraphWalker struct includes a lock that's passed down to BuiltinEvalContext and guards access to interpolation variables as they're written using SetVariables. The likely problem being expressed in hashicorp#5733 is that the same map reference is also passed down to the Interpolater.Variables field, which is used for variable lookup. Here, we plumb the same lock we're using to guard access for writes down and acquire it before doing variable reads as well. It's not as fine grained as perhaps it could be, but all the context tests pass and I believe this should address hashicorp#5733.
|
Sorry for the delay. This does indeed look good now with 0.6.14. Thanks! |
|
Hooray! Closing 👍 |
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
ghost
locked and limited conversation to collaborators
We have a 'reasonably complex' project structure - a lot of modules, null_resources and other goodies to help modularize our environment.
Since upgrading to 0.6.11 and 0.6.12 (could've been earlier too - but we really started noticing the problem lately) we now see the terraform process completely die with exit code 2 - there's basically no output at all (unless you turn on debug logging) - the process just bombs without showing anything.
I managed to get a trace log of the issue today and captured the call stacks which I'll add here:
https://gist.github.com/mrwilby/e78ed1274a46c54ae3f9
I have the full trace log but I am not willing to post that in public as it contains a lot of project information.
The text was updated successfully, but these errors were encountered: