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/72543344-ad79-4f90-b8a5-13392db1e7afn%40googlegroups.com.