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

Search Discussions

  • Dave Cheney at Jul 14, 2013 at 11:15 pm
    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 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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brendan Tracey at Jul 14, 2013 at 11:33 pm
    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

    On Jul 14, 2013, at 4:15 PM, Dave Cheney wrote:

    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 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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dominik Honnef at Jul 15, 2013 at 3:18 am

    Brendan Tracey writes:

    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.
    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.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Minux at Jul 15, 2013 at 6:52 am

    On Mon, Jul 15, 2013 at 7:12 AM, Brendan Tracey 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.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • John Nagle at Jul 15, 2013 at 4:48 pm

    On 7/14/2013 11:52 PM, minux wrote:
    On Mon, Jul 15, 2013 at 7:12 AM, Brendan Tracey wrote:

    for one, the race detector can only detect race if it's actually happening
    in the code.
         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



    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dmitry Vyukov at Jul 15, 2013 at 12:01 pm

    On Mon, Jul 15, 2013 at 3:12 AM, Brendan Tracey 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.

    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.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brendan Tracey at Jul 15, 2013 at 2:10 pm
    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)?
    On Jul 15, 2013, at 5:00 AM, Dmitry Vyukov wrote:

    On Mon, Jul 15, 2013 at 3:12 AM, Brendan Tracey
    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.

    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?"
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dmitry Vyukov at Jul 15, 2013 at 2:51 pm

    On Mon, Jul 15, 2013 at 6:09 PM, Brendan Tracey 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).

    On Jul 15, 2013, at 5:00 AM, Dmitry Vyukov wrote:

    On Mon, Jul 15, 2013 at 3:12 AM, Brendan Tracey
    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.

    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?"
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brendan Tracey at Jul 15, 2013 at 3:51 pm

    On Jul 15, 2013, at 7:51 AM, Dmitry Vyukov wrote:

    On Mon, Jul 15, 2013 at 6:09 PM, Brendan Tracey
    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.
    On Jul 15, 2013, at 5:00 AM, Dmitry Vyukov wrote:

    On Mon, Jul 15, 2013 at 3:12 AM, Brendan Tracey
    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.

    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?"
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dmitry Vyukov at Jul 15, 2013 at 3:53 pm
    Sorry
    http://play.golang.org/p/ijG7teQBhx


    On Mon, Jul 15, 2013 at 7:51 PM, Brendan Tracey
    wrote:
    On Jul 15, 2013, at 7:51 AM, Dmitry Vyukov wrote:

    On Mon, Jul 15, 2013 at 6:09 PM, Brendan Tracey
    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.
    On Jul 15, 2013, at 5:00 AM, Dmitry Vyukov wrote:

    On Mon, Jul 15, 2013 at 3:12 AM, Brendan Tracey
    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.

    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?"
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rémy Oudompheng at Jul 15, 2013 at 3:41 pm
    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.

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJul 14, '13 at 11:12p
activeJul 15, '13 at 4:48p
posts12
users7
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase