As I shared, ANY data race can lead to a panic. You can be interfering with the GC object tracking.
I agree with you that it seems not possible, but I was surprised to learn that it is.
It is not the case in Java as there are assignment guarantees even without concurrency - but the data race can cause a crash if using native code. On Nov 19, 2024, at 5: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. Yes, I do agree that it's easy to write data race code. Sorry, I didn't make it clear. I have the data race report, my concerning is to prove the relation bewteen data race and the crash.The code I want is actually that can trigger a runtime reportZombies crash.
A "reportZombies" crash can have several reasons; including, but not limited to, a data race. I still don't understand how you think a generic program that causes a "reportZombies" crash will help you identify the bug in your program. I suggest starting by fixing the data races in your program. If that doesn't eliminate the "reportZombies" crashes then you have a more difficult problem to diagnose. Start by trying to identify whether you have pure Go code that is converting pointers to uintptr's (and not correctly managing such pointers), or (more likely) you are using CGo to link with non-Go code and your Go code is not correctly managing the lifecycle of the non-Go code data. Kurtis Rader Caretaker of the exceptional canines Junior and Hank
--
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/CA%2BhP-7uvPnY7OKgDwYpUYALPzb0zDVJmwYxkzKBZnGOKEY5J1A%40mail.gmail.com.
--
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/5436E317-2FF9-4712-AC19-3E62A15D7AB4%40ix.netcom.com.
|
