runtime: valgrind thinks adjustpointer sometimes operates on uninitialized values

[rolandshoemaker]

When running a binary under Valgrind (using the instrumentation from https://go.dev/cl/674077), we sometimes get errors indicating that the pointer being adjusted is considered uninitialized by valgrind. This seems somewhat unlikely, since p is a pointer on a stack in order for it to get into adjustpointer, but perhaps it's actually something?

Unclear the best way to debug this, I spent some time looking into it and couldn't find a compelling reason. Perhaps Valgrind itself can be used to figure it out(!) but I'm not entirely sure the best way to go about that.

E.g.

==3329570== Conditional jump or move depends on uninitialised value(s)
==3329570==    at 0x457C26: runtime.adjustpointer (stack.go:636)
==3329570==    by 0x457F84: runtime.adjustframe (stack.go:740)
==3329570==    by 0x4587BD: runtime.copystack (stack.go:986)
==3329570==    by 0x458D84: runtime.newstack (stack.go:1175)
==3329570==    by 0x47517C: runtime.morestack.abi0 (asm_amd64.s:620)
==3329570==    by 0x51CA3F: ??? (in /usr/local/google/home/bracewell/go-src/src/gc-test-new)
==3329570==  Uninitialised value was created by a stack allocation
==3329570==    at 0x47F7CF: internal/godebug.update (godebug.go:241)

[gabyhelp]

Related Issues

• runtime/checkptr：Proposed some changes to pointer detection #68220 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[randall77]

adjustpointer might be adjusting dead slots, which might contain junk.

In some cases (stack objects, maybe others?) we only know that the stack slot is pointer typed. We don't know whether it is still live, or (more relevant here) not initialized yet.

Does valgrind understand Go stacks enough to know what parts of the stack frame are initialized?

[mknyszek]

CC @golang/runtime