-
Notifications
You must be signed in to change notification settings - Fork 19k
runtime: GODEBUG=profstackdepth=N not usable with //go:debug #71187
Copy link
Copy link
Open
Labels
BugReportIssues describing a possible bug in the Go implementation.Issues describing a possible bug in the Go implementation.NeedsDecisionFeedback is required from experts, contributors, and/or the community before a change can be made.Feedback is required from experts, contributors, and/or the community before a change can be made.compiler/runtimeIssues related to the Go compiler and/or runtime.Issues related to the Go compiler and/or runtime.
Milestone
Metadata
Metadata
Assignees
Labels
BugReportIssues describing a possible bug in the Go implementation.Issues describing a possible bug in the Go implementation.NeedsDecisionFeedback is required from experts, contributors, and/or the community before a change can be made.Feedback is required from experts, contributors, and/or the community before a change can be made.compiler/runtimeIssues related to the Go compiler and/or runtime.Issues related to the Go compiler and/or runtime.
Type
Projects
Status
Todo
Go 1.23 increased the default profiling stack depth from 32 to 128 (https://go.dev/cl/572396). It also introduced
GODEBUG=profstackdepth=32as a way to revert back to the old default (https://go.dev/cl/581917).However, that new GODEBUG doesn't appear in the
internal/godebugstable, which means it is not eligible for use ingo.modgodebugblocks or//go:debugdirectives (https://go.dev/doc/godebug).Given that the main purpose of this GODEBUG is for compatibility, it seems like it should be eligible for use there, and perhaps this should be backported to 1.23.
This came up in #69590 (comment), where a user would like the old behavior.
One thing that is a bit unclear to me: I think if we add this as an "official" compatibility GODEBUG, then we will tie it to the version in
go.mod. i.e., modules withgo 1.22.0will useprofstackdepth=32, even if built with 1.23. They must setgo 1.23.0to get the new behavior. That is probably the right thing to do, but might be a bit odd to change in a minor release.cc @felixge @golang/runtime