traffic_crashlog: emit a well-formed report when the backtrace is empty#13360
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR hardens traffic_crashlog crash-report generation so that an “apparently successful” ServerBacktrace() call is only treated as success when it actually yields a non-empty backtrace, ensuring the existing fallback paths produce a well-formed report in fast-abort / attach-too-late scenarios.
Changes:
- Treat
ServerBacktrace()as successful only whentraceis non-null and non-empty (trace[0] != '\0'). - Ensure
traceis freed on fallthrough paths to avoid leaking the empty/unused trace buffer. - Improve the explanatory comment describing the “success-but-empty” backtrace scenario and why the fallback is preferred.
ServerBacktrace() reports success but yields no frames when the target's thread list is unreadable -- e.g. a fast-aborting target has already exited by the time the forked helper attaches. The success check only tested for a null trace, so an empty-but-non-null trace fell into the success path and produced a report with no backtrace and no explanation. Require a non-empty trace before treating ServerBacktrace as having succeeded, so the empty case falls through to the existing in-process-backtrace and diagnostic-message fallback.
moonchen
force-pushed
the
uring/pr1-crashlog
branch
from
b4ac004 to
683387b
Compare
JosiahWI
approved these changes
Jul 3, 2026
JosiahWI
reviewed
Jul 3, 2026
| free(trace); | ||
| return true; | ||
| } | ||
| free(trace); |
Contributor
There was a problem hiding this comment.
This is a use case for free accepting nullptr. Interesting!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
ServerBacktrace()can succeed with an empty backtrace — the target's thread list was unreadable, e.g. a fast-aborting target already exited before the forked helper attached. The success check only tests for a null trace, so the crash log ends up with no backtrace section and the existing fallbacks (in-process backtrace, diagnostic message) never run.Fix
Require a non-empty trace before taking the success path, so the empty case falls through to the fallbacks; free the trace when falling through.
Easy to hit with any startup
Fatal(e.g. a listen-port bind failure): the process is gone before the helper attaches.