-
Notifications
You must be signed in to change notification settings - Fork 17.4k
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.
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
log/slog: log.Fatal() reports wrong source location when both log.Lshortfile or log.Llongfile and slog with source is enabled #67362
Labels
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Comments
CC @robpike. |
dmitshur
added
the
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
label
May 14, 2024
cc @jba for slog |
jba
changed the title
log: Fatal() reports wrong source location when both log.Lshortfile or log.Llongfile and slog with source is enabled
log/slog: log.Fatal() reports wrong source location when both log.Lshortfile or log.Llongfile and slog with source is enabled
May 15, 2024
This is a slog bug. Changing the title. |
Ran into this too. Here's a dirty workaround; type pcHandler struct {
slog.Handler
skip int
}
func (h pcHandler) Handle(ctx context.Context, r slog.Record) error {
var pcs [2]uintptr
n := runtime.Callers(h.skip, pcs[:])
frames := runtime.CallersFrames(pcs[:n])
frame, _ := frames.Next()
if frame.Function == "log.Fatal" {
r.PC = pcs[1]
}
return h.Handler.Handle(ctx, r)
} |
Change https://go.dev/cl/588335 mentions this issue: |
op
added a commit
to op/go
that referenced
this issue
May 25, 2024
This makes all log functions keep a consistent call structure to be nice with the handleWriter in the slog package which expects a strict level of 4. Fixes golang#67362.
op
added a commit
to op/go
that referenced
this issue
May 25, 2024
This makes all log functions keep a consistent call structure to be nice with the handleWriter in the slog package which expects a strict level of 4. Fixes golang#67362. Change-Id: Ib967c696074b1ca931f6656dd27ff1ec484233b8
op
added a commit
to op/go
that referenced
this issue
May 25, 2024
This makes all log functions keep a consistent call structure to be nice with the handleWriter in the slog package which expects a strict level of 4. Fixes golang#67362. Change-Id: Ib967c696074b1ca931f6656dd27ff1ec484233b8
op
added a commit
to op/go
that referenced
this issue
May 25, 2024
This makes all log functions keep a consistent call structure to be nice with the handleWriter in the slog package which expects a strict level of 4. Fixes golang#67362. Change-Id: Ib967c696074b1ca931f6656dd27ff1ec484233b8
op
added a commit
to op/go
that referenced
this issue
May 25, 2024
This makes all log functions keep a consistent call structure to be nice with the handleWriter in the slog package which expects a strict level of 4. Fixes golang#67362. Change-Id: Ib967c696074b1ca931f6656dd27ff1ec484233b8
op
added a commit
to op/go
that referenced
this issue
May 25, 2024
This makes all log functions keep a consistent call structure to be nice with the handleWriter in the slog package which expects a strict level of 4. Fixes golang#67362. Change-Id: Ib967c696074b1ca931f6656dd27ff1ec484233b8
op
added a commit
to op/go
that referenced
this issue
May 28, 2024
This makes all log functions keep a consistent call structure to be nice with the handleWriter in the slog package which expects a strict level of 4. Fixes golang#67362. Change-Id: Ib967c696074b1ca931f6656dd27ff1ec484233b8
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Go version
go version go1.21.5 darwin/arm64
Output of
go env
in your module/workspace:What did you do?
Our applications have
log.Lshortfile
set and while migrating tolog/slog
, we noticed that in a few spots where we calllog.Fatal()
that the source line information points to inside the standard library as opposed to the line where the log was called.Other package-level functions such as
log.Print()
report the correct source line location.log.Llongfile
exhibits the same bug.Playground: https://go.dev/play/p/k-eOzUuhr1f
What did you see happen?
When slog is enabled with source location, we see the following:
What did you expect to see?
When slog is disabled, we see the following:
I would expect with slog enabled, we should see the following:
The text was updated successfully, but these errors were encountered: