-
-
Notifications
You must be signed in to change notification settings - Fork 7.5k
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
fatal error: concurrent map read and map write #2549
Comments
Probably same as #2224. If you could invite me so I could have a look that would be great. |
Done and done @bep. Thanks much. |
Thanks, @rdwatters -- I can reproduce with this one, which means I can figure it out. |
@rdwatters in your case it is the nested partial invocations that makes the race happen: taxonomy.html -> partial -> partial That should be enough to create a test case. |
@bep. Just to make sure I follow. Is this an example? That's too bad if it's the nested partials that are causing the issue since the partials/components/title comes in awfully handy. That said, I haven't had a single issue at build time (I'm using Netlify for CD), but the local deve definitely seems to be getting worse. |
Removing the nested partial makes the rebuilds stable -- but that is just a symptom ... or something. We'll fix this. Regular builds seems to be stable with your site. |
Yes. |
Great. Thanks much for looking into this. Should I post an issue elsewhere (perhaps add to the previous golang thread? I ask because I use that heading partial all over the place. At this point, I'm not sure it's worth extracting just to prevent the panic during dev. |
No, I will try go boil it down to a simpler reproduction and post it at Go stdlib. If it is an issue we can probably work around it on Hugo side by adding a mutex. |
Here is a stack of the crash with the race detector enabled:
|
The Go issue: |
Thanks for the due diligence on this @bep. I offered the repo on the Go issue thread as well. |
OK -- now I have this issue on my site ass well ... pain in the ass. I think the cause of it was adding the second |
The good news: I have a small reproduceable (I will try to make it even smaller) for the Go team -- the bad news is I don't see a workaround, yet ... |
This was breaking Hugo. See gohugoio/hugo#2549
Saw that workaround offered by cespare on the other thread. Glad it's been added to the milestones. I'm cool with pressing up/enter in the terminal each time it panics until v18. Cheers. |
Or you could build from source ... |
Or you could point out the obvious, which I should already know. Haha. Thanks! |
i'm obtaining the same error in a random way, as you can see, three hugo compilation runs fine , but another compilation raise the error. $ hugo $ hugo $ hugo $ hugo goroutine 211 [running]: goroutine 1 [chan send]: goroutine 214 [semacquire]: goroutine 210 [chan receive]: goroutine 213 [runnable]: goroutine 212 [runnable]: |
@VladimirPlokhov this issue is closed as in -- fixed. Please don't comment on fixed issues if you have nothing new to add. |
I'm getting this same error when attempting to build using v0.75.x on AWS Codebuild (but strangely not when using v0.75.1 locally on macOS). Installing Hugo using the following commands: wget https://github.com/gohugoio/hugo/releases/download/v0.75.1/hugo_extended_0.75.1_Linux-64bit.deb
dpkg -i hugo_extended_0.75.1_Linux-64bit.deb``` |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Left this on the forums as well. Getting this at a rate of almost every other save/livereload at this point. Unfortunately, the repo is private, but I can invite if necessary for a more comprehensive look at the code. Here's a link to the gist:
https://gist.github.com/rdwatters/ab7d3226fff97c7b432e5264fab57466
The text was updated successfully, but these errors were encountered: