FAQ
Howdy

What does it mean when a test run with -race dies with:

FATAL: Reached goroutine limit

?

It seems the limit is defined in the race .syso. What is the limit? Can it
be made higher? Any other info?

Regards

Albert

--

Search Discussions

  • Minux at Jan 22, 2013 at 4:48 pm

    On Wed, Jan 23, 2013 at 12:27 AM, Albert Strasheim wrote:

    Howdy

    What does it mean when a test run with -race dies with:

    FATAL: Reached goroutine limit

    ?

    It seems the limit is defined in the race .syso. What is the limit? Can it
    be made higher? Any other info?
    enlarge
    const int kMaxGoroutinesEver = 128*1024;
    in compiler-rt/lib/tsan/go/tsan_go.cc

    and rebuild the syso by following tip.golang.org/src/pkg/runtime/race/README
    (note: you really need to use the specified gcc version if the build fails)

    --
  • Dmitry Vyukov at Jan 23, 2013 at 7:20 am

    On Tuesday, January 22, 2013 8:48:11 PM UTC+4, minux wrote:

    On Wed, Jan 23, 2013 at 12:27 AM, Albert Strasheim <ful...@gmail.com<javascript:>
    wrote:
    Howdy

    What does it mean when a test run with -race dies with:

    FATAL: Reached goroutine limit

    ?

    It seems the limit is defined in the race .syso. What is the limit? Can
    it be made higher? Any other info?
    enlarge
    const int kMaxGoroutinesEver = 128*1024;
    in compiler-rt/lib/tsan/go/tsan_go.cc

    and rebuild the syso by following
    tip.golang.org/src/pkg/runtime/race/README
    (note: you really need to use the specified gcc version if the build fails)

    Yes, you can increase it by changing the constant and recompiling.
    This is unfortunate consequence of the fact that race detector uses Go
    runtime unique increasing goroutine indices as identifiers (
    https://code.google.com/p/go/issues/detail?id=4286).
    I will try to fix it before Go 1.1.

    Btw, do yo hit it on a test or on a real program? If it is a program, was
    it serving infinite stream of requests? If it's a test, then you can
    consider decreasing data set size or some other constants, because the race
    detector does not need heavy stress tests to detect bugs.


    --
  • Albert Strasheim at Jan 23, 2013 at 7:23 am
    Hello
    On Wed, Jan 23, 2013 at 9:20 AM, Dmitry Vyukov wrote:
    On Tuesday, January 22, 2013 8:48:11 PM UTC+4, minux wrote:
    On Wed, Jan 23, 2013 at 12:27 AM, Albert Strasheim <ful...@gmail.com>
    wrote:
    Howdy
    What does it mean when a test run with -race dies with:
    FATAL: Reached goroutine limit
    ?
    Yes, you can increase it by changing the constant and recompiling.
    This is unfortunate consequence of the fact that race detector uses Go
    runtime unique increasing goroutine indices as identifiers
    (https://code.google.com/p/go/issues/detail?id=4286).
    I will try to fix it before Go 1.1.
    Btw, do yo hit it on a test or on a real program? If it is a program, was it
    serving infinite stream of requests? If it's a test, then you can consider
    decreasing data set size or some other constants, because the race detector
    does not need heavy stress tests to detect bugs.
    I hit it while running a unit test for this code:

    http://code.google.com/p/goexecutor/

    Cheers

    Albert

    --
  • Dmitry Vyukov at Jan 23, 2013 at 7:47 am

    On Wed, Jan 23, 2013 at 11:23 AM, Albert Strasheim wrote:
    Hello
    On Wed, Jan 23, 2013 at 9:20 AM, Dmitry Vyukov wrote:
    On Tuesday, January 22, 2013 8:48:11 PM UTC+4, minux wrote:
    On Wed, Jan 23, 2013 at 12:27 AM, Albert Strasheim <ful...@gmail.com>
    wrote:
    Howdy
    What does it mean when a test run with -race dies with:
    FATAL: Reached goroutine limit
    ?
    Yes, you can increase it by changing the constant and recompiling.
    This is unfortunate consequence of the fact that race detector uses Go
    runtime unique increasing goroutine indices as identifiers
    (https://code.google.com/p/go/issues/detail?id=4286).
    I will try to fix it before Go 1.1.
    Btw, do yo hit it on a test or on a real program? If it is a program, was it
    serving infinite stream of requests? If it's a test, then you can consider
    decreasing data set size or some other constants, because the race detector
    does not need heavy stress tests to detect bugs.
    I hit it while running a unit test for this code:

    http://code.google.com/p/goexecutor/

    I think you can decrease some constants in the test.

    --
  • Dmitry Vyukov at Jan 23, 2013 at 8:17 am
    Or you can disable the TestGen test under race detector (// +build !race)
    On Wed, Jan 23, 2013 at 11:46 AM, Dmitry Vyukov wrote:
    On Wed, Jan 23, 2013 at 11:23 AM, Albert Strasheim wrote:
    Hello
    On Wed, Jan 23, 2013 at 9:20 AM, Dmitry Vyukov wrote:
    On Tuesday, January 22, 2013 8:48:11 PM UTC+4, minux wrote:
    On Wed, Jan 23, 2013 at 12:27 AM, Albert Strasheim <ful...@gmail.com>
    wrote:
    Howdy
    What does it mean when a test run with -race dies with:
    FATAL: Reached goroutine limit
    ?
    Yes, you can increase it by changing the constant and recompiling.
    This is unfortunate consequence of the fact that race detector uses Go
    runtime unique increasing goroutine indices as identifiers
    (https://code.google.com/p/go/issues/detail?id=4286).
    I will try to fix it before Go 1.1.
    Btw, do yo hit it on a test or on a real program? If it is a program, was it
    serving infinite stream of requests? If it's a test, then you can consider
    decreasing data set size or some other constants, because the race detector
    does not need heavy stress tests to detect bugs.
    I hit it while running a unit test for this code:

    http://code.google.com/p/goexecutor/

    I think you can decrease some constants in the test.
    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJan 22, '13 at 4:27p
activeJan 23, '13 at 8:17a
posts6
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase