Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

runtime/pprof: TestCPUProfile fails, "profile too short" on go 1.0.3 #4466

Closed
gopherbot opened this issue Nov 29, 2012 · 4 comments
Closed

runtime/pprof: TestCPUProfile fails, "profile too short" on go 1.0.3 #4466

gopherbot opened this issue Nov 29, 2012 · 4 comments
Labels
FrozenDueToAge
Milestone
Go1.1

Comments

@gopherbot
Copy link

by jsawczuk:

When trying to build Go 1.0.3, TestCPUProfile fails on a VirtualBox with Fedora 16 as
its guest OS. I read somewhere that the IO APIC VBox setting is relevant here, and its
enabled. The build succeeds in Go 1.0.2.

Test output:

--- FAIL: TestCPUProfile (0.46 seconds)
pprof_test.go:57:   profile too short: [0x0 0x3 0x0 0x2710 0x0 0x0 0x1 0x0]
FAIL
FAIL    runtime/pprof   0.470s

uname -a:

Linux jsawdev 3.6.6-1.fc16.x86_64 #1 SMP Mon Nov 5 16:56:43 UTC 2012 x86_64 x86_64
x86_64 GNU/Linux

Relevant diff in pprof_test.go:

+   l := len(bytes) / int(unsafe.Sizeof(uintptr(0)))
    val := *(*[]uintptr)(unsafe.Pointer(&bytes))
-   val = val[:len(bytes)/int(unsafe.Sizeof(uintptr(0)))]
+   val = val[:l]
 
-   if len(val) < 10 {
+   if l < 13 {
        t.Fatalf("profile too short: %#x", val)
    }

Let me know if I can provide any additional information. Thanks!
@rsc
Copy link
Contributor

rsc commented Nov 29, 2012

Comment 1:

profile too short means that the cpu is not delivering profiling events.
That's easy to believe in a virtualized environment, and of course profiling
is suspect in those environments anyway.
I wouldn't worry much about it.

@rsc
Copy link
Contributor

rsc commented Dec 9, 2012

Comment 2:

I am a little surprised this changed from 1.0.2 to 1.0.3. I looked through the diffs,
and the only addition is the new EOD marker, and I don't see how that would affect this
unless it is mistakenly causing us to throw away profiles. But I can't see that it's
doing that.
Can you please confirm that it still works at 1.0.2 in your VM? If so, can you please
try running the test for both of these versions:
hg update -r 29990fa0951c
hg update -r 92e962e13197
If it works in the first but fails in the second then we have a problem.
Thanks.

Labels changed: added priority-later, go1.1maybe, removed priority-triage, go1.1.

Status changed to WaitingForReply.

@gopherbot
Copy link
Author

Comment 3 by jsawczuk:

I ran these builds a few times each and they don't consistently pass (and neither does
1.0.2 anymore). I've never run into this issue on any non-virtualized machines, so I'd
say the fault is with my VM as well. Thanks for looking into it though, sorry for the
inconvenience.

@ianlancetaylor
Copy link
Contributor

Comment 4:

Thanks for following up.  Let us know if you happen to pin this down further.

Status changed to Retracted.

@rsc rsc added this to the Go1.1 milestone Apr 14, 2015
@rsc rsc removed the go1.1maybe label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.1
Development

No branches or pull requests
3 participants
@rsc @ianlancetaylor @gopherbot