Is the go race detector error free?

[Brendan Tracey]

The race detector blog post says "It will not issue false positives, so take its warnings seriously". Is it also true that the race detector doesn't issue false negatives? I'm told that in the general case race detection is related to the halting problem, but since it is analyzing running code it seems like this shouldn't actually be an issue. I'm having some strange issues with my concurrent code, and this code passes the race detector. I'm wondering if this means I can rule out a race condition. Thanks.

[Dave Cheney]

I interpret the warning as the race detector will not cry wolf for code patterns it knows how to instrument, but it does not know how to instrument everything (yet)

* have you tried tip, there are new instruments available ?

* can you explain more about the problem you are seeing ?

* can you please show code. 

On  how15/07/2013, at 9:12, Brendan Tracey <tracey....@gmail.com> wrote:

The race detector blog post says "It will not issue false positives, so take its warnings seriously". Is it also true that the race detector doesn't issue false negatives? I'm told that in the general case race detection is related to the halting problem, but since it is analyzing running code it seems like this shouldn't actually be an issue. I'm having some strange issues with my concurrent code, and this code passes the race detector. I'm wondering if this means I can rule out a race condition. Thanks.

--
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.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Brendan Tracey]

Thanks for the reply Dave and for the offer of help. I haven't done sufficient homework on my end yet to isolate the problem. When I do, I'll be sure to ask for help if I'm not sure how to fix it.

Thanks for all your help

[Dominik Honnef]

It's usually said about the race detector that it has no false positives
but possibly false negatives, both because of missing
instrumentalisation as mentioned by Dave and because it only detects
races that actually occured during runtime.

[minux]

On Mon, Jul 15, 2013 at 7:12 AM, Brendan Tracey <tracey....@gmail.com> wrote:

The race detector blog post says "It will not issue false positives, so take its warnings seriously". Is it also true that the race detector doesn't issue false negatives? I'm told that in the general case race detection is related to the halting problem, but since it is analyzing running code it seems like this shouldn't actually be an issue. I'm having some strange issues with my concurrent code, and this code passes the race detector. I'm wondering if this means I can rule out a race condition. Thanks.

for one, the race detector can only detect race if it's actually happening in the code.

[Dmitry Vyukov]

Yes, formally the race detector is false-negative-free. But there are
2 points to it:
1. As others pointed out, there are implementation issues and possible
bugs, e.g. some memory accesses may be non-instrumented and invisible
to the race detector. I would say that it's currently (on tip) in a
quite good shape.
However, false positives are highly visible. While false negatives are
usually invisible. So if you will track the problem and will turn out
to be a missed race, please report it. Such reports are invaluable.
2. The definition of "false-negative-free" is not what an end user may
expect it to be. An end user may expect "is my program race free?".
While the race detector answers -- "is this particular of a program is
race free?"

Do not assume that the program is race-free is the race detector is silent.
Run the program with the race detector under different workloads and
different values of GOMAXPROCS.

[Brendan Tracey]

I will keep track if it turns out in the end to be a race condition.

>
> Do not assume that the program is race-free is the race detector is silent.
> Run the program with the race detector under different workloads and
> different values of GOMAXPROCS.

Based on what you said though about it being false-negative free, I can assume that the particular run of the program was race condition free (at least as far as the authors are aware, noting, as you said, that false negatives are silent)?

[Dmitry Vyukov]

On Mon, Jul 15, 2013 at 6:09 PM, Brendan Tracey
<tracey....@gmail.com> wrote:
> I will keep track if it turns out in the end to be a race condition.
>
>
>>
>> Do not assume that the program is race-free is the race detector is silent.
>> Run the program with the race detector under different workloads and
>> different values of GOMAXPROCS.
>
> Based on what you said though about it being false-negative free, I can assume that the particular run of the program was race condition free (at least as far as the authors are aware, noting, as you said, that false negatives are silent)?

I do not understand the question.


Note also that the race detector most likely won't report the race in
the following program:
http://play.golang.org/

The race detector tracks so called happens-before relations. And in
most executions of the program accesses to x happened to be
synchronized (one happens-before the other) by means of logMu, while
on source code level x and logMu are clearly unrelated (the latter is
not meant to synchronize accesses to the former).

[Rémy Oudompheng]

Speaking about bugs, I think last week I found a data corruption
caused by race instrumentation.

I will try to narrow it down and file an issue.

Rémy.

[Brendan Tracey]

On Jul 15, 2013, at 7:51 AM, Dmitry Vyukov <dvy...@google.com> wrote:

> On Mon, Jul 15, 2013 at 6:09 PM, Brendan Tracey
> <tracey....@gmail.com> wrote:
>> I will keep track if it turns out in the end to be a race condition.
>>
>>
>>>
>>> Do not assume that the program is race-free is the race detector is silent.
>>> Run the program with the race detector under different workloads and
>>> different values of GOMAXPROCS.
>>
>> Based on what you said though about it being false-negative free, I can assume that the particular run of the program was race condition free (at least as far as the authors are aware, noting, as you said, that false negatives are silent)?
>
>
> I do not understand the question.
>
>
> Note also that the race detector most likely won't report the race in
> the following program:
> http://play.golang.org/
>
> The race detector tracks so called happens-before relations. And in
> most executions of the program accesses to x happened to be
> synchronized (one happens-before the other) by means of logMu, while
> on source code level x and logMu are clearly unrelated (the latter is
> not meant to synchronize accesses to the former).
>

You didn't post the link you intended to (I imagine), but you did answer the question. Thanks.

[Dmitry Vyukov]

Sorry
http://play.golang.org/p/ijG7teQBhx


On Mon, Jul 15, 2013 at 7:51 PM, Brendan Tracey

[John Nagle]

Right. You must have a test case that forces a race condition.
If your program is driven by external events, like a web
server, it may be hard to force a rare race condition by
testing.

It's very easy in Go to share variables between goroutines.
It can happen by accident, especially because slices are shared
between arrays. Send a slice across a channel, or pass one as
a parameter to a goroutine, and you've created a condition where
two goroutines can access the same variable without locking.

John Nagle