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.

Sign up for GitHub

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: logget fails log entry on Plan 9 #9846

Closed
0intro opened this issue Feb 11, 2015 · 4 comments
Closed

runtime: logget fails log entry on Plan 9 #9846

0intro opened this issue Feb 11, 2015 · 4 comments
Labels
FrozenDueToAge

Comments

@0intro
Copy link
Member

0intro commented Feb 11, 2015

Since CL 3972, the TestTraceStress test from the runtime/pprof package is intermittently failing.

http://build.golang.org/log/c809f02dcf6b0b387c548cca1d0dc2b4568e8e35

runtime: logget fails log entry= 359 b.log[0]= 201745413 b.log[1]= 105798405 b.log[2]= 201806134 b.log[3]= 1678060806
fatal error: logget: get not legal

runtime stack:
runtime.throw(0x19adc8, 0x15)
    /tmp/buildlet-scatch646466550/go/src/runtime/panic.go:511 +0x71
runtime.(*workbuf).logget(0x306b60c0, 0x167)
    /tmp/buildlet-scatch646466550/go/src/runtime/mgc.go:681 +0x144
runtime.getempty(0x167, 0x166)
    /tmp/buildlet-scatch646466550/go/src/runtime/mgc.go:738 +0xa3
runtime.greyobject(0x1039dae0, 0x1f8ac000, 0x148, 0x10380ca3, 0x0, 0x303a3000, 0x303a3000)
    /tmp/buildlet-scatch646466550/go/src/runtime/mgc.go:359 +0x3dc
runtime.scanobject(0x1f8ac000, 0x3d8000, 0x0, 0x303a3000, 0x303a2f00)
    /tmp/buildlet-scatch646466550/go/src/runtime/mgc.go:432 +0x263
runtime.drainworkbuf(0x303a2f00, 0x303a3001)
    /tmp/buildlet-scatch646466550/go/src/runtime/mgc.go:525 +0x111
runtime.scanblock(0x0, 0x0, 0x0, 0x303a3000, 0x103845a0)
    /tmp/buildlet-scatch646466550/go/src/runtime/mgc.go:477 +0xd3
runtime.gcmark_m()
    /tmp/buildlet-scatch646466550/go/src/runtime/mgc.go:1747 +0x3f
runtime.systemstack(0x1039e500)
    /tmp/buildlet-scatch646466550/go/src/runtime/asm_386.s:254 +0x56
runtime.mstart()
    /tmp/buildlet-scatch646466550/go/src/runtime/proc1.go:671

goroutine 6 [running]:
runtime.systemstack_switch()
    /tmp/buildlet-scatch646466550/go/src/runtime/asm_386.s:209 fp=0x103a0f84 sp=0x103a0f80
runtime.gcwork(0x0)
    /tmp/buildlet-scatch646466550/go/src/runtime/malloc.go:396 +0x1b6 fp=0x103a0fdc sp=0x103a0f84
runtime.backgroundgc()
    /tmp/buildlet-scatch646466550/go/src/runtime/mgc0.go:66 +0x45 fp=0x103a0ff0 sp=0x103a0fdc
runtime.goexit()
    /tmp/buildlet-scatch646466550/go/src/runtime/asm_386.s:2410 +0x1 fp=0x103a0ff4 sp=0x103a0ff0
created by runtime.gogc
    /tmp/buildlet-scatch646466550/go/src/runtime/malloc.go:343 +0xc3

goroutine 1 [chan receive]:
testing.RunTests(0x1d2038, 0x25b280, 0xc, 0xc, 0x1)
    /tmp/buildlet-scatch646466550/go/src/testing/testing.go:557 +0x86b
testing.(*M).Run(0x103d6060, 0x271140)
    /tmp/buildlet-scatch646466550/go/src/testing/testing.go:486 +0x5d
main.main()
    runtime/pprof/_test/_testmain.go:76 +0x176

goroutine 50 [runnable]:
runtime/pprof_test.parseEvents(0x108ea000, 0x681ae, 0x6f000, 0x1f8ac000, 0x22c88, 0x25800, 0x0, 0x0)
    /tmp/buildlet-scatch646466550/go/src/runtime/pprof/trace_parser_test.go:212 +0xa6d
runtime/pprof_test.parseTrace(0x303a7ff0, 0x103f7e60, 0x0, 0x0, 0x0, 0x0, 0x0)
    /tmp/buildlet-scatch646466550/go/src/runtime/pprof/trace_parser_test.go:63 +0xb8
runtime/pprof_test.TestTraceStress(0x103f7e00)
    /tmp/buildlet-scatch646466550/go/src/runtime/pprof/trace_test.go:201 +0xb24
testing.tRunner(0x103f7e00, 0x25b2f8)
    /tmp/buildlet-scatch646466550/go/src/testing/testing.go:448 +0xb4
created by testing.RunTests
    /tmp/buildlet-scatch646466550/go/src/testing/testing.go:556 +0x833

goroutine 82 [select (no cases)]:
runtime/pprof_test.func·025()
    /tmp/buildlet-scatch646466550/go/src/runtime/pprof/trace_test.go:189 +0x22
created by runtime/pprof_test.TestTraceStress
    /tmp/buildlet-scatch646466550/go/src/runtime/pprof/trace_test.go:190 +0xa13
FAIL    runtime/pprof   38.819s
@0intro 0intro self-assigned this Feb 11, 2015
@bradfitz
Copy link
Contributor

/cc @RLH

@aclements
Copy link
Member

/cc me

@aclements
Copy link
Member

Working theory: a15818f removed the zeroing of workbufs after they were allocated with persistentAlloc. This is fine on POSIX systems that use anonymous mmap to get memory for persistentAlloc, but Plan9 uses sbrk. I'm not sure how sbrk works on Plan9, but if something did a negative sbrk (maybe within a page), followed by the sbrk for this persistentAlloc, it could return non-zeroed memory.

@aclements
Copy link
Member

I had missed that sbrk was our own implementation and not a syscall on Plan 9. But I was right that sysAlloc can return non-zeroed memory on Plan 9 because sysFree has an optimization to roll back the brk without zeroing it, causing the next sysAlloc to return potentially non-zeroed memory.

@golang golang locked and limited conversation to collaborators Jun 25, 2016
@rsc rsc unassigned 0intro Jun 23, 2022
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
No milestone
Development

No branches or pull requests
4 participants
@bradfitz @aclements @0intro @gopherbot