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

runtime: "unexpected signal during runtime execution" during bgscavenge on plan9-386-0intro #35456

bcmills opened this issue Nov 8, 2019 · 4 comments
help wanted NeedsInvestigation OS-Plan9


Copy link

@bcmills bcmills commented Nov 8, 2019

From plan9-386-0intro (, a cmd/vet test failure that appears to have nothing to do with cmd/vet:

--- FAIL: TestVet (1.94s)
    --- FAIL: TestVet/assign (0.43s)
        vet_test.go:162: error check failed: 
            assign.go:18: missing error "self-assignment of x to x"
            assign.go:20: missing error "self-assignment of s.x to s.x"
            assign.go:22: missing error "self-assignment of s.l.0. to s.l.0."
            Unmatched Errors:
            fatal error: unexpected signal during runtime execution
            [signal sys: trap: fault write code=0x0 addr=0x0 pc=0xa960]
            goroutine 4 [running]:
            runtime.throw(0x96394d, 0x2a)
            	/tmp/workdir-gnot/go/src/runtime/panic.go:1106 +0x63 fp=0x11429f44 sp=0x11429f30 pc=0x2e783
            	/tmp/workdir-gnot/go/src/runtime/os_plan9.go:79 +0x333 fp=0x11429f78 sp=0x11429f44 pc=0x2b033
            runtime.newobject(0x92d1a0, 0x0)
            	/tmp/workdir-gnot/go/src/runtime/malloc.go:1153 fp=0x11429f7c sp=0x11429f78 pc=0xa960
            	/tmp/workdir-gnot/go/src/runtime/mgcscavenge.go:211 +0x5b fp=0x11429fe8 sp=0x11429f7c pc=0x1d83b
            	/tmp/workdir-gnot/go/src/runtime/asm_386.s:1337 +0x1 fp=0x11429fec sp=0x11429fe8 pc=0x573f1
            created by runtime.gcenable
            	/tmp/workdir-gnot/go/src/runtime/mgc.go:215 +0x6a
            goroutine 1 [chan receive, locked to thread]:
            runtime.gopark(0x96ee48, 0x1143c030, 0x1143170e, 0x2)
            	/tmp/workdir-gnot/go/src/runtime/proc.go:304 +0xd8
            runtime.chanrecv(0x1143c000, 0x0, 0x11400001, 0x1515a)
            	/tmp/workdir-gnot/go/src/runtime/chan.go:563 +0x275
            runtime.chanrecv1(0x1143c000, 0x0)
            	/tmp/workdir-gnot/go/src/runtime/chan.go:433 +0x1c
            	/tmp/workdir-gnot/go/src/runtime/mgc.go:216 +0x7e
            	/tmp/workdir-gnot/go/src/runtime/proc.go:166 +0x183
            	/tmp/workdir-gnot/go/src/runtime/asm_386.s:1337 +0x1
FAIL	cmd/vet	34.760s

CC @aclements @mknyszek @0intro @fhs

@bcmills bcmills added help wanted OS-Plan9 NeedsInvestigation labels Nov 8, 2019
@bcmills bcmills added this to the Unplanned milestone Nov 8, 2019
Copy link

@mknyszek mknyszek commented Nov 8, 2019

This is very odd. It's failing very, very early in the runtime (right when the background scavenger is spinning up) trying to allocate a timer. And the problem seems to be that newobject has a nil type parameter? I'm not even sure how that can happen.

Copy link

@ianlancetaylor ianlancetaylor commented Nov 8, 2019

The type parameter passed to newobject is 0x92d1a0. The 0x0 is the result parameter. The addr=0x0 printed at the start of the backtrace is meaningless, as this is not a fault signal, it is a trap signal. The trap signal does not set the address field (sigcode1) on Plan 9.

But that said I have no idea why the binary would get a trap signal. I don't know enough about Plan 9 to know what might cause that. If this happened only once I'm inclined to ignore it.

CC @0intro

Copy link

@fhs fhs commented Nov 22, 2019

Not sure if this is related, but cmd/vet crashed from a trap signal in a trybot run:

fatal error: sys: trap: general protection violation pc=0x00200393
[signal sys: trap: code=0x0 addr=0x0 pc=0x200393]

goroutine 1 [running]:
runtime.throw(0x10812000, 0x35)
	/tmp/workdir-gnot/go/src/runtime/panic.go:1106 +0x63 fp=0x108a1498 sp=0x108a1484 pc=0x2da03
	/tmp/workdir-gnot/go/src/runtime/os_plan9.go:104 +0x289 fp=0x108a14cc sp=0x108a1498 pc=0x2a3a9
go/internal/gcimporter.(*importReader).declare(0x108a5b40, 0x338e40, 0x108d9140)
	/tmp/workdir-gnot/go/src/go/internal/gcimporter/iimport.go:310 +0x43 fp=0x108a14e4 sp=0x108a14cc pc=0x200393
go/internal/gcimporter.(*importReader).obj(0x108a5b40, 0x10821ff4, 0x4)
	/tmp/workdir-gnot/go/src/go/internal/gcimporter/iimport.go:270 +0x796 fp=0x108a1580 sp=0x108a14e4 pc=0x200136
go/internal/gcimporter.(*iimporter).doDecl(0x10862500, 0x108d9020, 0x10821ff4, 0x4)
	/tmp/workdir-gnot/go/src/go/internal/gcimporter/iimport.go:202 +0x160 fp=0x108a15c8 sp=0x108a1580 pc=0x1ff1f0
go/internal/gcimporter.iImportData(0x10851410, 0x108dfce0, 0x109e0001, 0x4ff96, 0x7fdff, 0x1085e820, 0x14, 0x0, 0x0, 0x0, ...)
	/tmp/workdir-gnot/go/src/go/internal/gcimporter/iimport.go:153 +0xb5f fp=0x108a1788 sp=0x108a15c8 pc=0x1fec0f
go/internal/gcimporter.Import(0x10851410, 0x108dfce0, 0x1085e820, 0x14, 0x0, 0x0, 0x108dabc0, 0x0, 0x0, 0x0)
	/tmp/workdir-gnot/go/src/go/internal/gcimporter/gcimporter.go:159 +0x421 fp=0x108a188c sp=0x108a1788 pc=0x1fda21
go/importer.(*gcimports).ImportFrom(0x108e17f0, 0x1085e820, 0x14, 0x0, 0x0, 0x0, 0x8c, 0x1085c630, 0x4e9324)
	/tmp/workdir-gnot/go/src/go/importer/importer.go:102 +0x58 fp=0x108a18b8 sp=0x108a188c pc=0x205008
go/importer.(*gcimports).Import(0x108e17f0, 0x1085e820, 0x14, 0x14, 0x1085c680, 0x291401)
	/tmp/workdir-gnot/go/src/go/importer/importer.go:95 +0x48 fp=0x108a18e0 sp=0x108a18b8 pc=0x204f88
cmd/vendor/, 0x14, 0x290cc0, 0x52d201, 0x0)
	/tmp/workdir-gnot/go/src/cmd/vendor/ +0x78 fp=0x108a1910 sp=0x108a18e0 pc=0x214748
cmd/vendor/, 0x1085e941, 0x14, 0x0, 0x0, 0xb4f00)
	/tmp/workdir-gnot/go/src/cmd/vendor/ +0x2b fp=0x108a1928 sp=0x108a1910 pc=0x21437b
go/types.(*Checker).importPackage(0x1085c7e0, 0x8b4, 0x1085e941, 0x14, 0x10860210, 0x20, 0x0)
	/tmp/workdir-gnot/go/src/go/types/resolver.go:158 +0x48e fp=0x108a1998 sp=0x108a1928 pc=0x1cf0ae
	/tmp/workdir-gnot/go/src/go/types/resolver.go:253 +0x383 fp=0x108a1cc4 sp=0x108a1998 pc=0x1cf573
go/types.(*Checker).checkFiles(0x1085c7e0, 0x108dabb8, 0x1, 0x2, 0x0, 0x0)
	/tmp/workdir-gnot/go/src/go/types/check.go:253 +0x89 fp=0x108a1ce8 sp=0x108a1cc4 pc=0x1b72d9
go/types.(*Config).Check(0x108dfd00, 0x10820bc2, 0x7, 0x10851410, 0x108dabb8, 0x1, 0x2, 0x108d8a20, 0x0, 0x1087cae0, ...)
	/tmp/workdir-gnot/go/src/go/types/api.go:348 +0xf4 fp=0x108a1d1c sp=0x108a1ce8 pc=0x1adab4
cmd/vendor/, 0x1087ca80, 0x10880500, 0x15, 0x20, 0x108a1e40, 0x1082089c, 0x108a1de8, 0x108ac020, 0x2cb0bc)
	/tmp/workdir-gnot/go/src/cmd/vendor/ +0x3e7 fp=0x108a1df0 sp=0x108a1d1c pc=0x213bb7
cmd/vendor/, 0x23, 0x10880500, 0x15, 0x20)
	/tmp/workdir-gnot/go/src/cmd/vendor/ +0xd8 fp=0x108a1f54 sp=0x108a1df0 pc=0x213288
cmd/vendor/, 0x15, 0x20)
	/tmp/workdir-gnot/go/src/cmd/vendor/ +0x1ed fp=0x108a1f98 sp=0x108a1f54 pc=0x21302d
	/tmp/workdir-gnot/go/src/cmd/vet/main.go:35 +0x276 fp=0x108a1fb8 sp=0x108a1f98 pc=0x24f726
	/tmp/workdir-gnot/go/src/runtime/proc.go:203 +0x261 fp=0x108a1ff0 sp=0x108a1fb8 pc=0x2fe71
	/tmp/workdir-gnot/go/src/runtime/asm_386.s:1337 +0x1 fp=0x108a1ff4 sp=0x108a1ff0 pc=0x53601

Copy link

@gopherbot gopherbot commented May 13, 2020

Change mentions this issue: dashboard: change "plan9" SlowBot alias to refer to plan9-arm

gopherbot pushed a commit to golang/build that referenced this issue May 13, 2020
The plan9-arm builder is currently passing fairly reliably on the
dashboard, whereas the plan9-386-0intro builder is frequently failing
with an "unexpected fault address".

Until the plan9-386-0intro build is fixed, the plan9-arm builder seems
more useful as a SlowBot to check architecture-agnostic changes that
affect plan9.

Updates golang/go#35456
Updates golang/go#22227

Change-Id: Ib5ecddafec91ca9274f9f0e15cb98621b41dda85
Run-TryBot: Bryan C. Mills <>
TryBot-Result: Gobot Gobot <>
Reviewed-by: Dmitri Shuralyov <>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
help wanted NeedsInvestigation OS-Plan9
None yet

No branches or pull requests

5 participants