8000 runtime: valgrind thinks adjustpointer sometimes operates on uninitialized values · Issue #73801 · golang/go · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
8000

runtime: valgrind thinks adjustpointer sometimes operates on uninitialized values #73801

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
rolandshoemaker opened this issue May 20, 2025 · 2 comments
Open

runtime: valgrind thinks adjustpointer sometimes operates on uninitialized values #73801

rolandshoemaker opened this issue May 20, 2025 · 2 comments
Labels
BugReport Issues describing a possible bug in the Go implementation. compiler/runtime Issues related to the Go compiler and/or runtime.

Comments

@rolandshoemaker
Copy link
Member

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)
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label May 20, 2025
@gabyhelp
Copy link

Related Issues

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

@gabyhelp gabyhelp added the BugReport Issues describing a possible bug in the Go implementation. label May 20, 2025
@randall77
Copy link
Contributor

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
BugReport Issues describing a possible bug in the Go implementation. compiler/runtime Issues related to the Go compiler and/or runtime.
Projects
Go Compiler / Runtime
Status: No status
Milestone
No milestone
Development

No branches or pull requests
4 participants
@rolandshoemaker @randall77 @gopherbot @gabyhelp
0