On Thursday, November 10, 2022 at 1:59:11 PM UTC-8 David Pacheco wrote:
> 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. > > That message is intended for people using Go to write their own programs, not for developers of Go itself. That said, -d=checkptr should work fine for most of all.bash. There's no reason it wouldn't work for say, the compress/gzip tests. But there are certainly tricky cases, like the runtime and the tests of the -d=checkptr feature itself. Back to the original problem, #53289. The last crash you posted looks like the go tool itself is the one crashing. That tool itself should run fine in checkptr mode. Maybe there's a way to hack the build script to run just that binary in checkptr mode. Maybe just hardcode a "if os.Args[0] == "go" { checkptr = true }" somewhere in runtime startup? > 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/6c944837-3045-4434-be27-f5ce43bed651n%40googlegroups.com.