FileWithLineNum returns incorrect line number in v1.31.1#7719
FileWithLineNum returns incorrect line number in v1.31.1#7719huningzizhitaibai wants to merge 2 commits intogo-gorm:masterfrom
Conversation
The introduction of CallerFrame in v1.31.1 increased the call stack depth, but the hardcoded skip value in runtime.Callers was not adjusted. This caused FileWithLineNum to report its own caller's line number instead of the original business code's line number. Also added a regression test to verify the fix.
|
It also corrects the caller resolution by walking the call stack and skipping GORM internals, and adds a regression test to ensure the reported file and line match the call site. Affected Areas• This summary was automatically generated by @propel-code-bot |
![propel-code-bot[bot]](https://avatars.githubusercontent.com/in/1179004?s=60&v=4){kind=small}
| pcs := [13]uintptr{} | ||
| // the third caller usually from gorm internal | ||
| len := runtime.Callers(3, pcs[:]) | ||
| frames := runtime.CallersFrames(pcs[:len]) | ||
| for i := 0; i < len; i++ { | ||
| // second return value is "more", not "ok" | ||
| frame, _ := frames.Next() | ||
| if (!strings.HasPrefix(frame.File, gormSourceDir) || | ||
| strings.HasSuffix(frame.File, "_test.go")) && !strings.HasSuffix(frame.File, ".gen.go") { | ||
| return string(strconv.AppendInt(append([]byte(frame.File), ':'), int64(frame.Line), 10)) | ||
| } |
There was a problem hiding this comment.
[Maintainability] [CodeDuplication] The FileWithLineNum() function now duplicates the exact logic from CallerFrame(). Both functions contain identical stack traversal code:
- Both call
runtime.Callers(3, pcs[:]) - Both iterate through frames with the same filtering logic
- Both check for
gormSourceDir,_test.go, and.gen.gofiles
Consider refactoring to eliminate this duplication:
func FileWithLineNum() string {
frame := CallerFrame()
if frame.PC != 0 {
return string(strconv.AppendInt(append([]byte(frame.File), ':'), int64(frame.Line), 10))
}
return ""
}This was the original implementation before this PR, which properly reused CallerFrame(). The duplication increases maintenance burden - any future changes to the filtering logic would need to be made in two places.
Context for Agents
[CodeDuplication] The `FileWithLineNum()` function now duplicates the exact logic from `CallerFrame()`. Both functions contain identical stack traversal code:
- Both call `runtime.Callers(3, pcs[:])`
- Both iterate through frames with the same filtering logic
- Both check for `gormSourceDir`, `_test.go`, and `.gen.go` files
Consider refactoring to eliminate this duplication:
```go
func FileWithLineNum() string {
frame := CallerFrame()
if frame.PC != 0 {
return string(strconv.AppendInt(append([]byte(frame.File), ':'), int64(frame.Line), 10))
}
return ""
}
```
This was the original implementation before this PR, which properly reused `CallerFrame()`. The duplication increases maintenance burden - any future changes to the filtering logic would need to be made in two places.
File: utils/utils.go
Line: 67
|
Note on Test Failures: |
|
Thanks for the PR! This overlaps with #7717 (same regression around FileWithLineNum / caller depth, plus a more robust wrapped-call regression test). To avoid duplicate fixes, I suggest we proceed with #7717 and close this one as a duplicate. If you’d like, you can help by reviewing / testing #7717. |
|
Closing as duplicate of #7717 (same FileWithLineNum regression fix, with a more robust regression test). |
2 participants
Fixes #7715
What did this pull request do?
Fixed a regression in FileWithLineNum introduced in v1.31.1. The new CallerFrame wrapper increased call stack depth, but runtime.Callers skip value was not updated. The skip value has been adjusted to correctly pinpoint the original caller.
User Case Description
When using v1.31.1 in the local project, FileWithLineNum() reports the line number of the internal FileWithLineNum() call itself instead of the business code line that triggered the GORM operation.