FAQ
Good news, everyone!

You might have seen my commits related to the race detector. Now it's in
pretty stable state, and I am looking for beta users before Go1.1 release.

To date the race detector has found 100+ bugs in various Go code, including 33
bugs in std lib<http://code.google.com/p/go/issues/list?can=1&q=ThreadSanitizer&colspec=ID+Status+Stars+Priority+Owner+Reporter+Summary&cells=tiles>
.

Currently it works on linux/windows/darwin amd64. You need tip >= r14902.

The usage is very simple -- you just need to add -race flag to go command:
$ go test -race mypkg // to test the package
$ go run -race mycmd // to run the command
$ go build -race mycmd // to build the command
$ go install -race mypkg // to install the package

You may start with running your tests. However sometimes tests have limited
coverage, especially with respect to concurrency. So it may be beneficial
to run the whole program built with -race under a realistic workload. If it
find a data race, it prints an informative report to stderr explaining
where the race has happened.

I would appreciate any feedback, in particular:
- if it does not work for you for any reason
- if you find anything non-obvious regarding the detector
- your success stories

And, yeah, it significantly increases both memory consumption (~5-10x) and
execution time (~2-20x).

Thanks!

Search Discussions

  • Daniel Theophanes at Nov 16, 2012 at 4:52 pm
    I don't see a way to give the race detector an alternate file to write to.
    Is there an way to direct what it writes to, ether by passing a channel to
    read from or a io.Writer? I ask because running it on windows while not
    logged on would require running it as a service, in which case the StdErr
    is hard to capture.

    -Daniel

    On Friday, November 16, 2012 8:35:28 AM UTC-8, Dmitry Vyukov wrote:

    Good news, everyone!

    You might have seen my commits related to the race detector. Now it's in
    pretty stable state, and I am looking for beta users before Go1.1 release.

    To date the race detector has found 100+ bugs in various Go code,
    including 33 bugs in std lib<http://code.google.com/p/go/issues/list?can=1&q=ThreadSanitizer&colspec=ID+Status+Stars+Priority+Owner+Reporter+Summary&cells=tiles>
    .

    Currently it works on linux/windows/darwin amd64. You need tip >= r14902.

    The usage is very simple -- you just need to add -race flag to go command:
    $ go test -race mypkg // to test the package
    $ go run -race mycmd // to run the command
    $ go build -race mycmd // to build the command
    $ go install -race mypkg // to install the package

    You may start with running your tests. However sometimes tests have
    limited coverage, especially with respect to concurrency. So it may be
    beneficial to run the whole program built with -race under a realistic
    workload. If it find a data race, it prints an informative report to stderr
    explaining where the race has happened.

    I would appreciate any feedback, in particular:
    - if it does not work for you for any reason
    - if you find anything non-obvious regarding the detector
    - your success stories

    And, yeah, it significantly increases both memory consumption (~5-10x) and
    execution time (~2-20x).

    Thanks!
  • Dmitry Vyukov at Nov 17, 2012 at 8:24 am

    On Friday, November 16, 2012 8:45:39 PM UTC+4, Daniel Theophanes wrote:

    I don't see a way to give the race detector an alternate file to write to.
    Is there an way to direct what it writes to, ether by passing a channel to
    read from or a io.Writer? I ask because running it on windows while not
    logged on would require running it as a service, in which case the StdErr
    is hard to capture.
    Hi Daniel,

    Good question. This functionality definitely must be provided. However, I
    think it's not a good idea to control it from within the process itself,
    and especially relying on such concepts as channels and io.Writer's. Some
    of the reasons are: (1) races can happen before that, (2) the runtime is
    implemented in C++ and does not know about chans and writers, (3) in a lot
    situations one can't modify sources while still need to redirect output.

    The current way to pass options to the race detector is GORACE env var
    (similarly to GOGC, GOTRACEBACK, etc).

    What do you think about
    $ GORACE="log_path=PATH" ./goprogram
    in such case the race detector will write logs to PATH.PID files?
    (by default we prefer to keep things aligned between our tools and that's
    what we have elsewhere)

    Can you set an additional env var for Windows service?

    Thanks for the feedback!



    On Friday, November 16, 2012 8:35:28 AM UTC-8, Dmitry Vyukov wrote:

    Good news, everyone!

    You might have seen my commits related to the race detector. Now it's in
    pretty stable state, and I am looking for beta users before Go1.1 release.

    To date the race detector has found 100+ bugs in various Go code,
    including 33 bugs in std lib<http://code.google.com/p/go/issues/list?can=1&q=ThreadSanitizer&colspec=ID+Status+Stars+Priority+Owner+Reporter+Summary&cells=tiles>
    .

    Currently it works on linux/windows/darwin amd64. You need tip >= r14902.

    The usage is very simple -- you just need to add -race flag to go command:
    $ go test -race mypkg // to test the package
    $ go run -race mycmd // to run the command
    $ go build -race mycmd // to build the command
    $ go install -race mypkg // to install the package

    You may start with running your tests. However sometimes tests have
    limited coverage, especially with respect to concurrency. So it may be
    beneficial to run the whole program built with -race under a realistic
    workload. If it find a data race, it prints an informative report to stderr
    explaining where the race has happened.

    I would appreciate any feedback, in particular:
    - if it does not work for you for any reason
    - if you find anything non-obvious regarding the detector
    - your success stories

    And, yeah, it significantly increases both memory consumption (~5-10x)
    and execution time (~2-20x).

    Thanks!
  • Daniel Theophanes at Nov 20, 2012 at 4:32 pm
    Realized I didn't reply to all. Sorry for any repeat messages.
    --
    Hi Dmitry,

    I'm not aware of a method to set an env var on a single windows service.
    However, I can just set a system env var; it seems unlikely I'll be
    checking many programs for races on a single box.

    Thanks,
    -Daniel

    On Sat, Nov 17, 2012 at 12:24 AM, Dmitry Vyukov wrote:
    On Friday, November 16, 2012 8:45:39 PM UTC+4, Daniel Theophanes wrote:

    I don't see a way to give the race detector an alternate file to write
    to. Is there an way to direct what it writes to, ether by passing a channel
    to read from or a io.Writer? I ask because running it on windows while not
    logged on would require running it as a service, in which case the StdErr
    is hard to capture.
    Hi Daniel,

    Good question. This functionality definitely must be provided. However, I
    think it's not a good idea to control it from within the process itself,
    and especially relying on such concepts as channels and io.Writer's. Some
    of the reasons are: (1) races can happen before that, (2) the runtime is
    implemented in C++ and does not know about chans and writers, (3) in a lot
    situations one can't modify sources while still need to redirect output.

    The current way to pass options to the race detector is GORACE env var
    (similarly to GOGC, GOTRACEBACK, etc).

    What do you think about
    $ GORACE="log_path=PATH" ./goprogram
    in such case the race detector will write logs to PATH.PID files?
    (by default we prefer to keep things aligned between our tools and that's
    what we have elsewhere)

    Can you set an additional env var for Windows service?

    Thanks for the feedback!



    On Friday, November 16, 2012 8:35:28 AM UTC-8, Dmitry Vyukov wrote:

    Good news, everyone!

    You might have seen my commits related to the race detector. Now it's in
    pretty stable state, and I am looking for beta users before Go1.1 release.

    To date the race detector has found 100+ bugs in various Go code,
    including 33 bugs in std lib<http://code.google.com/p/go/issues/list?can=1&q=ThreadSanitizer&colspec=ID+Status+Stars+Priority+Owner+Reporter+Summary&cells=tiles>
    .

    Currently it works on linux/windows/darwin amd64. You need tip >= r14902.

    The usage is very simple -- you just need to add -race flag to go
    command:
    $ go test -race mypkg // to test the package
    $ go run -race mycmd // to run the command
    $ go build -race mycmd // to build the command
    $ go install -race mypkg // to install the package

    You may start with running your tests. However sometimes tests have
    limited coverage, especially with respect to concurrency. So it may be
    beneficial to run the whole program built with -race under a realistic
    workload. If it find a data race, it prints an informative report to stderr
    explaining where the race has happened.

    I would appreciate any feedback, in particular:
    - if it does not work for you for any reason
    - if you find anything non-obvious regarding the detector
    - your success stories

    And, yeah, it significantly increases both memory consumption (~5-10x)
    and execution time (~2-20x).

    Thanks!
  • Dmitry Vyukov at Nov 20, 2012 at 3:28 pm

    On Fri, Nov 16, 2012 at 8:35 PM, Dmitry Vyukov wrote:
    Good news, everyone!

    You might have seen my commits related to the race detector. Now it's in
    pretty stable state, and I am looking for beta users before Go1.1 release.

    To date the race detector has found 100+ bugs in various Go code, including
    33 bugs in std lib.

    Currently it works on linux/windows/darwin amd64. You need tip >= r14902.

    The usage is very simple -- you just need to add -race flag to go command:
    $ go test -race mypkg // to test the package
    $ go run -race mycmd // to run the command
    $ go build -race mycmd // to build the command
    $ go install -race mypkg // to install the package

    You may start with running your tests. However sometimes tests have limited
    coverage, especially with respect to concurrency. So it may be beneficial to
    run the whole program built with -race under a realistic workload. If it
    find a data race, it prints an informative report to stderr explaining where
    the race has happened.

    I would appreciate any feedback, in particular:
    - if it does not work for you for any reason
    - if you find anything non-obvious regarding the detector
    - your success stories

    And, yeah, it significantly increases both memory consumption (~5-10x) and
    execution time (~2-20x).

    I am also interested in situations where you find the reports
    misleading or difficult to understand, e.g. wrong line numbers,
    function names, etc.
    And if you just run it and it finds nothing, would be good to hear as well.
  • Dmitry Vyukov at Nov 28, 2012 at 4:44 pm

    On Friday, November 16, 2012 8:35:28 PM UTC+4, Dmitry Vyukov wrote:

    Good news, everyone!

    You might have seen my commits related to the race detector. Now it's in
    pretty stable state, and I am looking for beta users before Go1.1 release.

    To date the race detector has found 100+ bugs in various Go code,
    including 33 bugs in std lib<http://code.google.com/p/go/issues/list?can=1&q=ThreadSanitizer&colspec=ID+Status+Stars+Priority+Owner+Reporter+Summary&cells=tiles>
    .

    Currently it works on linux/windows/darwin amd64. You need tip >= r14902.

    The usage is very simple -- you just need to add -race flag to go command:
    $ go test -race mypkg // to test the package
    $ go run -race mycmd // to run the command
    $ go build -race mycmd // to build the command
    $ go install -race mypkg // to install the package

    You may start with running your tests. However sometimes tests have
    limited coverage, especially with respect to concurrency. So it may be
    beneficial to run the whole program built with -race under a realistic
    workload. If it find a data race, it prints an informative report to stderr
    explaining where the race has happened.

    I would appreciate any feedback, in particular:
    - if it does not work for you for any reason
    - if you find anything non-obvious regarding the detector
    - your success stories

    And, yeah, it significantly increases both memory consumption (~5-10x) and
    execution time (~2-20x).

    Thanks!

    Hi,

    I've wrote Race Detector Manual:
    https://code.google.com/p/go-wiki/wiki/RaceDetector
    I will appreciate if you review it. What is not clear? What needs to be
    added?

    Note that GORACE=log_path/history_size is not yet available in Go tip, you
    need to build the runtime from sources. I will integrate it soon.

    Thanks!
  • Brainman at Nov 28, 2012 at 9:39 pm
    Very nice. Thank you.

    Alex
  • Minux at Nov 29, 2012 at 12:14 am

    On Thu, Nov 29, 2012 at 12:44 AM, Dmitry Vyukov wrote:

    I've wrote Race Detector Manual:
    https://code.google.com/p/go-wiki/wiki/RaceDetector
    I will appreciate if you review it. What is not clear? What needs to be
    added?
    Two tiny errors (typo) spotted and fixed.
    This manual is great. Do you plan to turn it into an article living under
    /doc/articles?
  • Dmitry Vyukov at Nov 29, 2012 at 7:42 am

    On Thu, Nov 29, 2012 at 4:14 AM, minux wrote:
    On Thu, Nov 29, 2012 at 12:44 AM, Dmitry Vyukov wrote:

    I've wrote Race Detector Manual:

    https://code.google.com/p/go-wiki/wiki/RaceDetector
    I will appreciate if you review it. What is not clear? What needs to be
    added?
    Two tiny errors (typo) spotted and fixed.
    This manual is great. Do you plan to turn it into an article living under
    /doc/articles?
    Thanks!
    Yes, I think it must be converted to an article in /doc before Go1.1.
    It's just simpler to do first rounds in wiki.

    Go team, do you mind submitting it to /doc/articles? If no, then it's
    better to do first rounds on review in wiki.
  • Minux at Nov 29, 2012 at 8:11 am

    On Thu, Nov 29, 2012 at 3:42 PM, Dmitry Vyukov wrote:
    This manual is great. Do you plan to turn it into an article living under
    /doc/articles?
    Yes, I think it must be converted to an article in /doc before Go1.1.
    It's just simpler to do first rounds in wiki.
    I think it also makes a good official blog post.
    Many articles are first posted on the official blog, and I think the race
    detector
    is such an important and useful feature that it should appear on the
    official blog.
  • Ian Lance Taylor at Nov 29, 2012 at 2:34 pm

    On Thu, Nov 29, 2012 at 12:10 AM, minux wrote:
    On Thu, Nov 29, 2012 at 3:42 PM, Dmitry Vyukov wrote:

    This manual is great. Do you plan to turn it into an article living
    under
    /doc/articles?
    Yes, I think it must be converted to an article in /doc before Go1.1.
    It's just simpler to do first rounds in wiki.
    I think it also makes a good official blog post.
    Many articles are first posted on the official blog, and I think the race
    detector
    is such an important and useful feature that it should appear on the
    official blog.
    I agree.

    Ian
  • Dmitry Vyukov at Dec 17, 2012 at 9:02 am

    On Wed, Nov 28, 2012 at 8:44 PM, Dmitry Vyukov wrote:
    On Friday, November 16, 2012 8:35:28 PM UTC+4, Dmitry Vyukov wrote:

    Good news, everyone!

    You might have seen my commits related to the race detector. Now it's in
    pretty stable state, and I am looking for beta users before Go1.1 release.

    To date the race detector has found 100+ bugs in various Go code,
    including 33 bugs in std lib.

    Currently it works on linux/windows/darwin amd64. You need tip >= r14902.

    The usage is very simple -- you just need to add -race flag to go command:
    $ go test -race mypkg // to test the package
    $ go run -race mycmd // to run the command
    $ go build -race mycmd // to build the command
    $ go install -race mypkg // to install the package

    You may start with running your tests. However sometimes tests have
    limited coverage, especially with respect to concurrency. So it may be
    beneficial to run the whole program built with -race under a realistic
    workload. If it find a data race, it prints an informative report to stderr
    explaining where the race has happened.

    I would appreciate any feedback, in particular:
    - if it does not work for you for any reason
    - if you find anything non-obvious regarding the detector
    - your success stories

    And, yeah, it significantly increases both memory consumption (~5-10x) and
    execution time (~2-20x).

    Thanks!


    Hi,

    I've wrote Race Detector Manual:
    https://code.google.com/p/go-wiki/wiki/RaceDetector
    I will appreciate if you review it. What is not clear? What needs to be
    added?

    Note that GORACE=log_path/history_size is not yet available in Go tip, you
    need to build the runtime from sources. I will integrate it soon.

    Hi,

    I've updated the runtime library, so now it supports GORACE flags (see
    description in the manual
    https://code.google.com/p/go-wiki/wiki/RaceDetector).
    Also fixed two compiler bugs that can lead to both false positives and
    false negatives. And fixed some other minor issues.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedNov 16, '12 at 4:42p
activeDec 17, '12 at 9:02a
posts12
users5
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase