Detecting race conditions

[Levi Durfee]

Hello,

While I was looking into a rarely occurring panic I used delve to debug the application. I set some log points in the Go standard library. I put one long point in src/net/lookup.go on line 298 so I could see that lookups were happening.

I passed "-race" to the delve "build-flags" option so I could detect race conditions.

I was able to find the race condition causing my panic and fix it, but I also noticed some other race conditions. I only see these race conditions when I have a log point set. The race conditions are in my code.

While it's easy to fix these race conditions in my code, I wonder if the log point might produce false positives. I've read that the Go race detector messages should not be taken lightly.

Could the log points be modifying the behavior, maybe slowing it down enough, so when debugging my app it has the opportunity to see the race conditions?

I'm using Go 1.20.4

https://github.com/golang/go/blob/go1.20.4/src/net/lookup.go#L298

Thanks,

Levi

[Axel Wagner]

Yes, logging changes behavior so that races might get exposed, both by slowing down the program and by introducing implicit synchronization points (the writes to the output happen under a mutex, AFAIK).

But it does not introduce false positives. It exposes true positives. The race are still there, even if the race detector can not detect them. Note that the race detector is a heuristic. It will never find all race conditions, only the ones encountered in the actual run.

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/4ea76bb3-57f5-42fa-8bce-249135161607n%40googlegroups.com.

[Stephen Illingworth]

But it does not introduce false positives. It exposes true positives. The race are still there, even if the race detector can not detect them. Note that the race detector is a heuristic. It will never find all race conditions, only the ones encountered in the actual run.

This is a great point. They are true positives.

I wonder if it's possible for the -race detector (via an optional flag) to introduce random lag in order to change the execution profile. I'm thinking that this would help to flush out these true positives. Fuzz testing but specifically for race detection.

[Axel Wagner]

I think the race detector is already relatively good at this. Like, AIUI, it keeps track of the partial order of events and checks if that is consistent and doesn't *purely* rely on writes actually happen concurrently.

I suspect (based on little) that in this case, the synchronization points that logging introduces might be more relevant. But I don't know.

--

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/8ca3eef8-74b4-4ed3-b9fb-4cc63f5d0a86n%40googlegroups.com.

[Levi Durfee]

Thank you all! This was very helpful :)

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHP9HQsut_5Sp9atQw4jQHQ1P3cYs1LT%3DHrrT-O0k%3DEzQ%40mail.gmail.com.