feat: record stacktrace for objects allocated in stack by Lslightly · Pull Request #76 · cloudwego/goref

Lslightly · 2026-06-23T08:24:20Z

What type of PR is this?

feat

Check the PR title.

This PR title match the format: <type>(optional scope): <description>
The description of this PR title is user-oriented and clear enough for others to understand.
Attach the PR updating the user documentation if the current PR requires user awareness at the usage level. User docs repo

(Optional) Translate the PR title into Chinese.

(Optional) More detailed description for this PR(en: English/zh: Chinese).

en: For local variables in stack, the stacktrace is recorded as pprofIndex
zh(optional): 对于栈上局部变量，在pprofIndex中记录栈帧。

Take test/testdata/manygo/main.go as an example. The flamegraph is as follows. There are 3 groups of goroutines whose members share same stacktrace.

Hope that it supplements goroutine leak profile.

(Optional) Which issue(s) this PR fixes:

Fixes #65

(optional) The PR that updates user documentation:

Lslightly · 2026-07-07T02:41:28Z

Hi @ppzqh and @jayantxie. Could you please review this pull request when you have time? I hope this PR resolves issue #65. Please let me know if there is anything that can be improved. Thanks for your time and effort in maintaining this tool!

ppzqh · 2026-07-08T03:12:44Z

Hi @Lslightly! Thanks for your work. I will review this.
BTW, please fix the error of tests.

…ference graph

Lslightly · 2026-07-08T03:43:40Z

An dummy function named stk_obj_split has been added to separate stacktrace and object reference graph.

I modified tests to use this dummy function to get the old "leaf" node, i.e. the object with the specified rootPrefixes. (Now go test -v -run=TestScenarios ./... passes. go test -v -race -coverprofile=coverage.out -covermode=atomic -coverpkg=github.com/cloudwego/goref/... ./... passes in my machine)

The flamegraph has been changed as follows, with a "stk_obj_split" frame separating stacktrace and object reference.

codecov · 2026-07-08T06:04:44Z

Codecov Report

❌ Patch coverage is 92.00000% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 61.83%. Comparing base (65e6157) to head (ec948c4).
⚠️ Report is 11 commits behind head on main.

Files with missing lines	Patch %	Lines
pkg/proc/protobuf.go	91.04%	3 Missing and 3 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##            main      #76       +/-   ##
==========================================
+ Coverage   2.70%   61.83%   +59.13%     
==========================================
  Files         15       16        +1     
  Lines       2221     2319       +98     
==========================================
+ Hits          60     1434     +1374     
+ Misses      2155      726     -1429     
- Partials       6      159      +153

Flag	Coverage Δ
unit	`61.83% <92.00%> (+59.13%)`	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Lslightly · 2026-07-08T12:57:32Z

Hi, @ppzqh. I fixed errors of tests. Do I need to add additional tests to increase the coverage rate? It seems that other merged PRs also have "Patch coverage" problem.

ppzqh · 2026-07-14T08:53:50Z

Yes, you need to add a TestScenario in the testCases. For now, the CI does not cover your added logic.

remove G<id>, the bottom of stacktrace

ppzqh · 2026-07-15T03:03:00Z

+			}
+			// write location
+			start := b.pb.startMessage()
+			b.pb.uint64Opt(tagLocation_ID, idx)


Location ID is keyed by function name, while Address and Line are PC-specific. Multiple PCs in the same function may therefore reuse incorrect source information. Since we only need function-level stacks, we can remove the PC/file/line metadata.

In 8ae7f8e, I simplify the stacktrace to function-level stacks and remove the PC/file/line metadata.

If delve provides correct PC/file/line, then adding them allows user to get correct pprof source view. I try to keep my opinion to add them, but I can't figure out the use case for source view now. File/line seems meaningless for a temporary memory snapshot and function is enough.

ppzqh · 2026-07-15T03:17:15Z


+const StackTraceObjSplitLine string = "stk_obj_split"
+
+func createStackTrace(b *profileBuilder, sf []proc.Stackframe, t *proc.Target, g *proc.G) *pprofIndex {


Since only function-level stacks are needed, createStackTrace should only append interned function names to pprofIndex. Keep Location and Function emission in flush, where stringIndex already guarantees deduplication. Then funcNameStrIdxSet is also not needed.

Besides, stack frames and the separator are attribution context, not object-reference edges. Using pushHead makes them consume maxRefDepth and can skip local roots on deep stacks. We might need another helper function of pprofIndex to handle this case.

Keep Location and Function emission in flush, where stringIndex already guarantees deduplication. Then funcNameStrIdxSet is also not needed.

8ae7f8e keeps Location and Function emission in flush and removes logic to add PC/file/line in Location.

funcNameStrIdxSet has been removed.

We might need another helper function of pprofIndex to handle this case.

newHeadWithDepth helper function is added and depth of stacktrace node's pprofIndex is set to -1.

Is it better to set the depth to negative stack depth? Depth of ReferenceStackBoundary is 0, then -1, -2, ... The change made to object reference is that depth of objects referenced by local variables increase by 1.

ppzqh · 2026-07-15T03:18:28Z

 					l.Name = sf[i].Current.Fn.Name + "." + l.Name
 					rv := ToReferenceVariable(l)
-					s.findRef(rv, nil)
+					s.findRef(rv, createStackTrace(s.pb, sf[i:], t, gr))


createStackTrace is called for every local variable, repeatedly rebuilding the same stack suffix. We can precompute immutable prefixes once per goroutine, build them in reverse to share suffix nodes, and reuse prefixes[i] for all locals in frame i

Thanks. That's true. We don't need to use pushHead repeatedly for each local variable to find pprofIndex previously built. prefixes[i] is much faster.

Done in 8ae7f8e with initStackTrace and pushReferenceStackBoundary

ppzqh · 2026-07-15T03:32:15Z

 	depth int
 }

+const StackTraceObjSplitLine string = "stk_obj_split"


rename to a clearer one, for example:
const ReferenceStackSeparator string = "[goref:reference-stack-boundary]"

1. remove file/line/PC metadata. 2. init stacktrace for each goroutine and reuse the stacktrace

Lslightly added 3 commits June 19, 2026 21:04

fix(pkg/proc): add mapping id in location in protobuf

e9db062

simply add stacktrace to pprofIndex

49eca3b

fix: avoid sharing pprofIndex node in stacktrace forest

6e9aaad

feat: add stk_obj_split dummy frame to split stacktrace and object re…

ec948c4

…ference graph

ppzqh reviewed Jul 14, 2026

View reviewed changes

Comment thread pkg/proc/protobuf.go Outdated

remove G<id> in the top of flamegraph

6d26613

remove G<id>, the bottom of stacktrace

Lslightly changed the title ~~feat: record stacktrace with goroutine id for objects allocated in stack~~ feat: record stacktrace for objects allocated in stack Jul 14, 2026

test: add StackTraceScenario

34d9fd7

Lslightly requested a review from ppzqh July 14, 2026 14:27

ppzqh reviewed Jul 15, 2026

View reviewed changes

Lslightly added 2 commits July 15, 2026 14:28

refactor: rename StackTraceObjSplitLine with ReferenceStackBoundary

6176ded

simplify stacktrace to function-level

8ae7f8e

1. remove file/line/PC metadata. 2. init stacktrace for each goroutine and reuse the stacktrace

Lslightly requested a review from ppzqh July 15, 2026 08:28

refactor: replace depth -1 with stackTracePprofIndexDepth const

e1cc226


		const StackTraceObjSplitLine string = "stk_obj_split"

		func createStackTrace(b profileBuilder, sf []proc.Stackframe, t proc.Target, g proc.G) pprofIndex {

Uh oh!

Conversation

Lslightly commented Jun 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What type of PR is this?

Check the PR title.

(Optional) Translate the PR title into Chinese.

(Optional) More detailed description for this PR(en: English/zh: Chinese).

(Optional) Which issue(s) this PR fixes:

(optional) The PR that updates user documentation:

Uh oh!

Lslightly commented Jul 7, 2026

Uh oh!

ppzqh commented Jul 8, 2026

Uh oh!

Lslightly commented Jul 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov Bot commented Jul 8, 2026

Codecov Report

Uh oh!

Lslightly commented Jul 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ppzqh commented Jul 14, 2026

Uh oh!

Uh oh!

ppzqh Jul 15, 2026

Choose a reason for hiding this comment

Uh oh!

Lslightly Jul 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ppzqh Jul 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ppzqh Jul 15, 2026

Choose a reason for hiding this comment

Uh oh!

Lslightly Jul 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ppzqh Jul 15, 2026

Choose a reason for hiding this comment

Uh oh!

Lslightly Jul 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Lslightly Jul 15, 2026

Choose a reason for hiding this comment

Uh oh!

ppzqh Jul 15, 2026

Choose a reason for hiding this comment

Uh oh!

Lslightly Jul 15, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

2 participants

Lslightly commented Jun 23, 2026 •

edited

Loading

Lslightly commented Jul 8, 2026 •

edited

Loading

Lslightly commented Jul 8, 2026 •

edited

Loading

Lslightly Jul 15, 2026 •

edited

Loading

ppzqh Jul 15, 2026 •

edited

Loading

Lslightly Jul 15, 2026 •

edited

Loading

Lslightly Jul 15, 2026 •

edited

Loading