Should be fixed by https://go-review.googlesource.com/c/go/+/448899
On Tuesday, November 8, 2022 at 4:34:00 PM UTC-8 Keith Randall wrote: > (Although normally lfstack nodes should not be heap allocated in the first > place?) > > > On Tuesday, November 8, 2022 at 4:32:11 PM UTC-8 Keith Randall wrote: > >> I don't think checkptr is intended to be applied blindly inside the >> runtime. The lfstack code is definitely doing things that checkptr was >> designed to catch and flag. >> Maybe the lfstack routines need a go:nocheckptr annotation? >> >> On Tuesday, November 8, 2022 at 11:21:30 AM UTC-8 David Pacheco wrote: >> >>> Hello, >>> >>> I’m trying to track down an issue reported by the Go memory allocator. >>> Most of the failure modes look like this one: >>> https://github.com/golang/go/issues/53289#issuecomment-1292744833 >>> but some of them look like: >>> https://github.com/golang/go/issues/53289#issuecomment-1289743609 >>> >>> It looks to me like these could be different manifestations of the same >>> issue. Following the advice in the second message, I tried to build Go and >>> run the test suite with `export GO_GCFLAGS="-d=checkptr"` in src/make.bash. >>> With that, I saw checkptr fail: >>> >>> fatal error: checkptr: pointer arithmetic result points to invalid >>> allocation >>> >>> goroutine 23171 [running]: >>> runtime.throw({0x8198ae?, 0xc0001560cf?}) >>> >>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/panic.go:1047 >>> >>> +0x5d fp=0xc0029f4e70 sp=0xc0029f4e40 pc=0x43c95d >>> runtime.checkptrArithmetic(0x770f40?, {0x0, 0x0, 0x0?}) >>> >>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/checkptr.go:70 >>> >>> +0xea fp=0xc0029f4eb0 sp=0xc0029f4e70 pc=0x40856a >>> runtime.lfstackUnpack(...) >>> >>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/lfstack_64bit.go:52 >>> runtime.(*lfstack).pop(...) >>> >>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/lfstack.go:47 >>> runtime.LFStackPop(...) >>> >>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/export_test.go:70 >>> runtime_test.TestLFStack(0xc000d26b60) >>> >>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/lfstack_test.go:52 >>> >>> +0x2de fp=0xc0029f4f70 sp=0xc0029f4eb0 pc=0x6deb9e >>> testing.tRunner(0xc000d26b60, 0x820dc0) >>> >>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/testing/testing.go:1446 >>> >>> +0x10b fp=0xc0029f4fc0 sp=0xc0029f4f70 pc=0x4fd94b >>> testing.(*T).Run.func1() >>> >>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/testing/testing.go:1493 >>> >>> +0x2a fp=0xc0029f4fe0 sp=0xc0029f4fc0 pc=0x4fe7ea >>> runtime.goexit() >>> >>> /home/dap/gotest/gocrash-1667603796953/thread-0-run-0/goroot/src/runtime/asm_amd64.s:1594 >>> >>> +0x1 fp=0xc0029f4fe8 sp=0xc0029f4fe0 pc=0x476121 >>> created by testing.(*T).Run >>> >>> That points to this code: >>> >>> https://github.com/golang/go/blob/39ac1fbd1393deed8888245dcf653220b14376f6/src/runtime/lfstack_64bit.go#L52 >>> >>> So I dug into the checkptr check and added some more printlns and I >>> found that this appears to be a heap address (0xc0001560c0), and >>> “originals” is empty (in checkptrArithmetic). Given that, I’m not sure how >>> this could ever work, since “originals” seems to come from the compiler (so >>> it doesn’t depend on runtime state). Can someone point me in the right >>> direction to better understanding what’s wrong here? Alternatively, is >>> there other information that would be useful to debug this problem? >>> >>> Thanks, >>> Dave >>> >> -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/c4dbf10f-824c-4b36-9f71-fd74a9c3ccdan%40googlegroups.com.
