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: crash in sbrk mode #53887

Open
cherrymui opened this issue Jul 14, 2022 · 2 comments
Open

runtime: crash in sbrk mode #53887

cherrymui opened this issue Jul 14, 2022 · 2 comments
Assignees
@mknyszek
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Backlog

Comments

@cherrymui
Copy link
Member

What version of Go are you using (go version)?

tip (f71f3d1)

Does this issue reproduce with the latest release?

Yes, reproducible with Go 1.18.
Go 1.17 seems to have fewer failures but can also fail.

What operating system and processor architecture are you using (go env)?

darwin/amd64

What did you do?

Run all.bash with GODEBUG=sbrk=1.

What did you expect to see?

Mostly work. Some test failures like GC accounting tests are reasonably expected.
Runtime crash is not expected (maybe except OOM, as it doesn't recycle memory in sbrk mode).

What did you see instead?

Runtime crash, which doesn't look like OOM.

fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1013e35]

goroutine 4 [running]:
runtime.throw({0x112fec7?, 0x8?})
        /Users/cherryyz/src/go/src/runtime/panic.go:1047 +0x5d fp=0xc00002bd80 sp=0xc00002bd50 pc=0x10357fd
runtime.sigpanic()
        /Users/cherryyz/src/go/src/runtime/signal_unix.go:819 +0x369 fp=0xc00002bdd0 sp=0xc00002bd80 pc=0x104a5e9
runtime.heapBits.bits(...)
        /Users/cherryyz/src/go/src/runtime/mbitmap.go:534
runtime.heapBits.isPointer(...)
        /Users/cherryyz/src/go/src/runtime/mbitmap.go:550
runtime.bulkBarrierPreWriteSrcOnly(0x1067a80?, 0xc00002be78?, 0x8)
        /Users/cherryyz/src/go/src/runtime/mbitmap.go:659 +0xd5 fp=0xc00002be28 sp=0xc00002bdd0 pc=0x1013e35
runtime.growslice(0x1102420, {0x17adc88?, 0x1031eb8?, 0x0?}, 0x48?)
        /Users/cherryyz/src/go/src/runtime/slice.go:294 +0x51b fp=0xc00002be90 sp=0xc00002be28 pc=0x104babb
runtime.doaddtimer(0x129c1a8, 0x1722dc8)
        /Users/cherryyz/src/go/src/runtime/time.go:301 +0x8c fp=0xc00002bee8 sp=0xc00002be90 pc=0x1053f6c
runtime.modtimer(0x1722dc8, 0xf46dcda7b668a, 0x0, 0x1132918, {0x1119020?, 0x120f7e0}, 0x0)
        /Users/cherryyz/src/go/src/runtime/time.go:507 +0x354 fp=0xc00002bf30 sp=0xc00002bee8 pc=0x1054a14
runtime.resettimer(...)
        /Users/cherryyz/src/go/src/runtime/time.go:554
time.resetTimer(...)
        /Users/cherryyz/src/go/src/runtime/time.go:235
runtime.(*scavengerState).sleep(0x120f7e0, 0x40c65c0000000000)
        /Users/cherryyz/src/go/src/runtime/mgcscavenge.go:464 +0x105 fp=0xc00002bfa0 sp=0xc00002bf30 pc=0x1021de5
runtime.bgscavenge(0x0?)
        /Users/cherryyz/src/go/src/runtime/mgcscavenge.go:626 +0x7f fp=0xc00002bfc8 sp=0xc00002bfa0 pc=0x10221ff
runtime.gcenable.func2()
        /Users/cherryyz/src/go/src/runtime/mgc.go:179 +0x26 fp=0xc00002bfe0 sp=0xc00002bfc8 pc=0x1018666
runtime.goexit()
        /Users/cherryyz/src/go/src/runtime/asm_amd64.s:1594 +0x1 fp=0xc00002bfe8 sp=0xc00002bfe0 pc=0x1066221
created by runtime.gcenable
        /Users/cherryyz/src/go/src/runtime/mgc.go:179 +0xaa

... other goroutine stacks omitted ... (I can post them if it helps)

FAIL    internal/intern 0.345s

A few packages' tests with similar stack traces, at least from bulkBarrierPreWriteSrcOnly above.

cc @mknyszek @golang/runtime
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 14, 2022
@cherrymui cherrymui added this to the Backlog milestone Jul 14, 2022
@cherrymui cherrymui added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 14, 2022
@cherrymui
Copy link
Member Author

Maybe we should not run write barriers at all in sbrk mode?

@mknyszek
Copy link
Contributor

Write barriers should probably just be disabled in sbrk mode. It's not like any of that memory is backed by GC metadata at all.

@mknyszek mknyszek modified the milestones: Backlog, Go1.20 Jul 20, 2022
@mknyszek mknyszek self-assigned this Jul 20, 2022
@cherrymui cherrymui modified the milestones: Go1.20, Backlog Jan 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mknyszek mknyszek

Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
Go Compiler / Runtime
Status: Todo
Milestone
Backlog
Development

No branches or pull requests
3 participants
@mknyszek @gopherbot @cherrymui