On Tue, Nov 19, 2024 at 3:50 AM Lin Lin <linsite.thin...@gmail.com> wrote: > > Thanks for your kind and instant reply. > > Allow me to explain myself a bit more. > > My code has two kinds of data races. First one is a global struct without any > pointer member being written and read by multiple Goroutines. Second one is a > struct's string member being written and read by multiple Gourotines. Data > race report shows no other unsafe or cgo usage. > > As far as I know, those kinds of data races may lead to a string or struct > value inconsistency within the race time window. How can that inconsistency > lead to a marked free bit in runtime.mspan? This really puzzles me. > Or maybe I took the wrong direction, this could be a hardware issue, like a > memory bit flip? But I failed to find any issue in the Go community.
A data race in a string can confuse the garbage collector. A string is a length and a pointer. If goroutine A updates the length in parallel with goroutine B updating the pointer, then the garbage collector can see a length and a pointer that do not correspond. If the length is longer than the pointer expects, that can cause the GC to mark some memory as allocated although it isn't. If that memory is not possible to allocate, because it is part of the GC metadata, the collector will crash. That is just one possible way to crash the program with a race. As a practical matter, it's a waste of time to try to reason about GC behavior when you know that the program has a race. As Kurtis says, fix the race first. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWYihCz%2B2j3jWJppHrZDZQK03eGc-2qLux_L_99YyCM4w%40mail.gmail.com.
