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
sync: inconsistent mutex state #41603
Comments
This looks like memory corruption. Have you tried running your program under the race detector? See https://blog.golang.org/race-detector . |
unfortunately my code running in produce environment that I have no fully control, and It cannot be reappeared in dev environment. I wrote a little test case but no race found. |
Can you please provide the full panic message. Thank you |
then will be business logic, take something from pool. my go version is 1.14 |
Timed out in state WaitingForInfo. Closing. (I am just a bot, though. Please speak up if this is a mistake or you have the requested information.) |
what's the final solution? I catch this bug again.
|
@beaquant can you provide a complete program that demonstrates the problem? |
It's very unlikely that we will be able to fix this issue if we can't reproduce it. I strongly encourage you to find a way to run the program under the race detector, as that is the most likely cause of the problem. Nobody else is reporting this problem, so the odds are against it being a bug in the standard library. In any case, if it is a bug in the standard library, we will need a way to reproduce the problem so that we can analyze it. The lines |
gopherbot, please don't do that. |
for
this said The old>>mutexWaiterShift != 0 here also use and the I think direct |
The expression
I'm sorry, I don't understand how this could happen. The I want to repeat that we are not seeing any bug reports about mutexes other than this one. Perhaps there is something wrong with this code, but it is not showing up as problems that people are reporting. If there is a real problem here, it should be possible to write a program that reproduces the problem. |
After all, using a variable is for reading and writing. But you have a lot of reading judgments that depend on this variable,
If there are even more cases, this is an expired value,is this judgment meaningful?(Does this fit the contextual business semantics?) Will it be in a for loop instead of waiting in runtime_SemacquireMutex? I think the reason why bugs do not often appear is because of the previous spin, and the other is that the goroutine is scheduled once every 10ms. Thank you! |
Changing the variable |
I don't think we're getting to the same point. If the atomic.CompareAndSwapInt32 is successful, the state will become the new value. This means that the new value also becomes the old value. We need to loop and think again, and go back to what I said above. Thanks. |
hello, has this been resolved? |
I also had this issue by using sync.pool |
I don't think that will help any. Note comment above:
|
I changed 'throw("sync: inconsistent mutex state")' to 'throw("sync: inconsistent mutex state, new="+strconv.FormatInt(new,10))' and it printed a huge number such as 2064149489, does that mean there is hundred millions of goroutines using the mutex? |
Either that, or there is some corruption happening that is overwriting the mutex. I would bet on the latter. |
have you solve this problem? |
I solved by removing some concurrent function call which may cause data race. But I don't know how this affected sync.mutex? func GetCostTreeFromCtx(ctx context.Context) *CostTree {
switch c := ctx.(type) {
case *blademaster.Context:
i, e := c.Get(_ctxTag)
if e {
ct := i.(*CostTree)
ct.CheckPoint = time.Now() // this line may cause data race
return ct
}
}
return NewCostTree()
} |
My code face "sync: inconsistent mutex state" panic, and I'm trying to fix it.
go/src/sync/mutex.go
Line 147 in d54a9a9
I wonder should this line be
old = atomic.LoadInt32(&m.state)
?go/src/sync/mutex.go
Line 140 in d54a9a9
It seems like there will be concurrent write in line: 212, and this line cannot guarantee
old
value is correct.I found https://groups.google.com/g/golang-nuts/c/Eq4CWTB6LhM/m/F0Lbgnfq4hQJ this post said it's a bug,
but 7 years past, it's still there, any purpose? Or is it safe to read int value from a pointer's field?
The text was updated successfully, but these errors were encountered: