FAQ
Hi all,
I’ve noticed this many times but when a stack trace is printed during
“go test”, the location information in the stack trace is off by a few
dozen lines (it seems to vary).

e.g.:

goroutine 30 [running]:
runtime.panic(0x294040, 0x599364)
         /usr/local/Cellar/go/1.3.3/libexec/src/pkg/runtime/panic.c:279 +0xf5
testing.func·006()
         /usr/local/Cellar/go/1.3.3/libexec/src/pkg/testing/testing.go:416 +0x176
runtime.panic(0x294040, 0x599364)
         /usr/local/Cellar/go/1.3.3/libexec/src/pkg/runtime/panic.c:248 +0x18d
foo/bar.(*someObj).someFunc(0xc2081a9500, 0xc208042210, 0xc208034108,
0x1, 0x1, 0x225000, 0x0, 0x0, 0x0, 0x0)
         foo/bar/_test/_obj_test/myfile.go:641 +0x602
foo/bar.(*someObj).parentFunc(0xc2081a9500, 0xc2080d7900, 0xd, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0)
         foo/bar/_test/_obj_test/myfile.go:284 +0xb72
[…]

myfile.go doesn’t even have 641 lines (it has 515). The stack frame
in parentFunc claims to have invoked someFunc at line 284, but that’s
wrong too. Line 284 doesn’t even fall in parentFunc’s definition.

In parentFunc()’s implementation, the only call to someFunc() is at
line 212 (so 72 lines before).

This seems to happen only during “go test”, and only when the stack
trace also shows the path to the .go file with the "_test/_obj_test”
intermediate directories added to the path of the file.

Is this a known issue?

--
Benoit "tsuna" Sigoure

--
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/d/optout.

Search Discussions

  • Tsuna at Nov 24, 2014 at 11:25 pm

    On Mon, Nov 24, 2014 at 3:22 PM, tsuna wrote:
    Hi all,
    I’ve noticed this many times but when a stack trace is printed during
    “go test”, the location information in the stack trace is off by a few
    dozen lines (it seems to vary).

    e.g.:

    goroutine 30 [running]:
    runtime.panic(0x294040, 0x599364)
    /usr/local/Cellar/go/1.3.3/libexec/src/pkg/runtime/panic.c:279 +0xf5
    testing.func·006()
    /usr/local/Cellar/go/1.3.3/libexec/src/pkg/testing/testing.go:416 +0x176
    runtime.panic(0x294040, 0x599364)
    /usr/local/Cellar/go/1.3.3/libexec/src/pkg/runtime/panic.c:248 +0x18d
    foo/bar.(*someObj).someFunc(0xc2081a9500, 0xc208042210, 0xc208034108,
    0x1, 0x1, 0x225000, 0x0, 0x0, 0x0, 0x0)
    foo/bar/_test/_obj_test/myfile.go:641 +0x602
    foo/bar.(*someObj).parentFunc(0xc2081a9500, 0xc2080d7900, 0xd, 0x0,
    0x0, 0x0, 0x0, 0x0, 0x0)
    foo/bar/_test/_obj_test/myfile.go:284 +0xb72
    […]

    myfile.go doesn’t even have 641 lines (it has 515). The stack frame
    in parentFunc claims to have invoked someFunc at line 284, but that’s
    wrong too. Line 284 doesn’t even fall in parentFunc’s definition.

    In parentFunc()’s implementation, the only call to someFunc() is at
    line 212 (so 72 lines before).

    This seems to happen only during “go test”, and only when the stack
    trace also shows the path to the .go file with the "_test/_obj_test”
    intermediate directories added to the path of the file.

    Is this a known issue?
    Ah, I ended up finding a possible explanation in the group’s archives
    after tried a different set of keywords:
    https://groups.google.com/d/topic/golang-nuts/GBeHbrIOxU4/discussion

    Apparently this is a known issue indeed that is a side effect of
    -cover (which we always use when running our tests). Hmm now I’m
    wondering whether we shouldn’t take -cover off. It’s too bad, I liked
    having it on all the time.

    --
    Benoit "tsuna" Sigoure

    --
    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/d/optout.
  • Rob Pike at Nov 24, 2014 at 11:27 pm
    If the test crashes, re-run without cover.

    -rob

    On Tue, Nov 25, 2014 at 10:24 AM, tsuna wrote:
    On Mon, Nov 24, 2014 at 3:22 PM, tsuna wrote:
    Hi all,
    I’ve noticed this many times but when a stack trace is printed during
    “go test”, the location information in the stack trace is off by a few
    dozen lines (it seems to vary).

    e.g.:

    goroutine 30 [running]:
    runtime.panic(0x294040, 0x599364)
    /usr/local/Cellar/go/1.3.3/libexec/src/pkg/runtime/panic.c:279 +0xf5
    testing.func·006()
    /usr/local/Cellar/go/1.3.3/libexec/src/pkg/testing/testing.go:416 +0x176
    runtime.panic(0x294040, 0x599364)
    /usr/local/Cellar/go/1.3.3/libexec/src/pkg/runtime/panic.c:248 +0x18d
    foo/bar.(*someObj).someFunc(0xc2081a9500, 0xc208042210, 0xc208034108,
    0x1, 0x1, 0x225000, 0x0, 0x0, 0x0, 0x0)
    foo/bar/_test/_obj_test/myfile.go:641 +0x602
    foo/bar.(*someObj).parentFunc(0xc2081a9500, 0xc2080d7900, 0xd, 0x0,
    0x0, 0x0, 0x0, 0x0, 0x0)
    foo/bar/_test/_obj_test/myfile.go:284 +0xb72
    […]

    myfile.go doesn’t even have 641 lines (it has 515). The stack frame
    in parentFunc claims to have invoked someFunc at line 284, but that’s
    wrong too. Line 284 doesn’t even fall in parentFunc’s definition.

    In parentFunc()’s implementation, the only call to someFunc() is at
    line 212 (so 72 lines before).

    This seems to happen only during “go test”, and only when the stack
    trace also shows the path to the .go file with the "_test/_obj_test”
    intermediate directories added to the path of the file.

    Is this a known issue?
    Ah, I ended up finding a possible explanation in the group’s archives
    after tried a different set of keywords:
    https://groups.google.com/d/topic/golang-nuts/GBeHbrIOxU4/discussion

    Apparently this is a known issue indeed that is a side effect of
    -cover (which we always use when running our tests). Hmm now I’m
    wondering whether we shouldn’t take -cover off. It’s too bad, I liked
    having it on all the time.

    --
    Benoit "tsuna" Sigoure

    --
    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/d/optout.
    --
    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/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedNov 24, '14 at 11:22p
activeNov 24, '14 at 11:27p
posts3
users2
websitegolang.org

2 users in discussion

Tsuna: 2 posts Rob Pike: 1 post

People

Translate

site design / logo © 2022 Grokbase