runtime: panic only with GOGC=on and highly concurrent programs also using cgo #30276
Comments
odeke-em
changed the title
odeke-em
added
the
NeedsInvestigation
|
Thank you for filling this bug report @sharpevo and welcome to the Go project! I shall page some experts from the related areas @ianlancetaylor @randall77 @aclements. |
|
Thank you odeke-em! Here are more errors that looks like memory corruption, with Error 2: variables in code: func (b *BlockingQueue) NextLockless() <-chan Item {
itemc := make(chan Item)
go func() {
runtime.KeepAlive(b.itemList)
defer close(itemc)
var cursor int
for cursor < len(b.itemList) {
cursor = <-b.Cursor
fmt.Println("CURSOR", cursor, len(b.itemList))
fmt.Printf("CURSOR queue: %#v\n", b) // <- this line, but printed as well in the log
fmt.Printf("CURSOR list: %#v\n", b.itemList)
if cursor > len(b.itemList)-1 {
break
}
if cursor == -1 {
break
}
var item interface{}
item = b.itemList[cursor]
fmt.Printf("BLOCKINGQUEUE: %#v\n", item)
itemc <- Item{cursor, item}
}
}()
return itemc
}Error 3: weird value const (
SYNC ExecutionType = iota
ASYNC
)
type StatementGroup struct {
Execution ExecutionType
ItemList *blockingqueue.BlockingQueue
}
func (g *StatementGroup) Execute(terminatec <-chan interface{}, completec chan<- interface{}) <-chan Response {
// ...
switch g.Execution {
case SYNC:
return bridge(terminatec, g.ExecuteSync(terminatec, completec))
case ASYNC:
return bridge(terminatec, g.ExecuteAsync(terminatec, completec))
default:
fmt.Printf("!!!!!! Execution type not matched\n%#v\n", g) // <- this line
}
// ...
}error: or Value of |
|
Error 2: memory corruption Instance is not accessable in the Lock function, even upgrading Golang to 1.11.5 func (b *BlockingQueue) Lock() {
fmt.Println(b) // <- this line
b.lock.Lock()
} |
|
Looking at that last error, it appears that a bad value for your Is there any way you can provide code and instructions so that we can reproduce the error ourselves? |
|
I've worked on some fixes for couple of days, and lines were changed in Recently, I found that there're many similar errors in the same app. Variables/channels might be GCed before called. Thank you for the patience! |
|
The problem has been resolved with the help of Tamás Gulácsi. Here is an analysis of the reason in shot. As JimB commented:
In the begining of the execution, I pass the It's difficult to figure out the real reason by stacktrace, as Jan Mercl posted:
Thank you again! |
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
The app was built to send instructions to devices concurrently with
cgo, in Linux and Windows platform. While running the app withGOGC=off, it works fine with many goroutines for a long period of time. Normally, there will be more errors when gc is turned on. IMO, it seems that variables are released by the garbage collector even when there are references. What's worse,runtime.KeepAlivedoes not help more.Error 1: standalone select statement
the code:
Error 2: variables in
fmt.Printlnthe code:
What did you expect to see?
no panic.
What did you see instead?
The reason might not be data race:
-raceflag, and there's no error reported.GOGC=off.The text was updated successfully, but these errors were encountered: