This is an automated email from the ASF dual-hosted git repository.

cmcfarlen pushed a commit to branch 10.2.x
in repository https://gitbox.apache.org/repos/asf/trafficserver.git

commit e09d13bc82935fded744c9e3f63e1fd6699a66cb
Author: Mo Chen <[email protected]>
AuthorDate: Sat Jul 4 19:45:26 2026 -0500

    traffic_crashlog: emit a well-formed report when the backtrace is empty 
(#13360)
    
    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.
    
    (cherry picked from commit 66845d68778062fe02cef685d6dabeea4b2266f4)
---
 src/traffic_crashlog/traffic_crashlog.cc | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/traffic_crashlog/traffic_crashlog.cc 
b/src/traffic_crashlog/traffic_crashlog.cc
index dd77893ffa..bf9925e834 100644
--- a/src/traffic_crashlog/traffic_crashlog.cc
+++ b/src/traffic_crashlog/traffic_crashlog.cc
@@ -145,14 +145,18 @@ crashlog_write_backtrace(FILE *fp, const crashlog_target 
&target)
   // can also happen without a debugger. Possibly in that case, there is a 
race with the
   // kernel locking the process information?
 
-  if (mgmterr == 0 && trace != nullptr) {
+  if (mgmterr == 0 && trace != nullptr && trace[0] != '\0') {
     // ServerBacktrace succeeded - this gives us backtraces for all threads.
     fprintf(fp, "%s", trace);
     free(trace);
     return true;
   }
+  free(trace);
 
-  // ServerBacktrace failed. Fall back to the in-process backtrace from the 
crashing thread.
+  // 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. Fall back to the in-process backtrace from the crashing 
thread rather
+  // than emitting an empty report.
   if ((target.flags & CRASHLOG_HAVE_BACKTRACE) && !target.backtrace.empty()) {
     fprintf(fp, "Crashing Thread Backtrace:\n%s", target.backtrace.c_str());
     return true;

Reply via email to