Hi Keith, Thanks for the helpful (and quick) reply! I gather you're right about not applying checkptr to Go's own test suite. I applied your patch, tried again, and started hitting failures in tests that were written for specific past issues. These seem like false positives.
Do you have other suggestions for how to debug this problem? I tried checkptr because when I ran the test suite and it failed with a panic message, that's what the panic message from the runtime said to try. Thanks! -- Dave On Tuesday, November 8, 2022 at 5:53:22 PM UTC-8 k...@google.com wrote: > > 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/7a54a621-b7bb-4965-9037-63f19795d2d1n%40googlegroups.com.
