lizthegrey commented on issue #1016:
URL: https://github.com/apache/arrow-go/issues/1016#issuecomment-5123782374

   Closing this heads-up — follow-up analysis showed the crash scenario cannot 
occur on any current Go runtime, so my original severity claim was overstated. 
Verified against the shipped binaries and go1.26.5 runtime source: (1) the 
affected functions are leaves whose epilogue never reloads LR from the stack, 
so normal execution never reads the clobbered slot; (2) the Go runtime never 
async-preempts assembly functions, so GC stack scanning, `runtime.Stack`, and 
goroutine profiles can never observe these frames; (3) the only readers — 
SIGPROF tracebacks and frame-pointer unwinds — fail soft, truncating the sample 
rather than throwing. Actual impact: corrupted CPU-profile samples and broken 
debugger/core-dump backtraces through the zstd decode frames on arm64. No 
crashes, no data corruption, Parquet/IPC decode output is always correct. The 
upstream fix (klauspost/compress#1176, description now revised) will flow to 
arrow-go via a routine dependency bump once released — nothing 
 to prioritise here. Apologies for arriving cold with an alarmist framing.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to