> > Do you have any evidence to the contrary?
Only that when Go 1.12 dropped, our similar function stopped working and that reducing the skip seemed to do the trick. The symptom was that our function would see an assembly file as the caller, which I interpreted to mean that we'd skipped too far. It only happened in goroutines with short stacks and I put it down to inlining. Quite possible that the "fix" I made was mistaken, or that runtime.Callers has been updated/fixed since then. In case you want to stare at my fix, here is the diff: https://github.com/projectcalico/libcalico-go/commit/1f1ababe294be198148c4232ef6c0344898d3b31#diff-7ab3329a79d456fe0d1747bba7344ac61e839f9097ae65d09b36f3c11ea13fbdL153 Looking back, I see three changes in that "fix": - Change to skip from 6 to 1 (and increase pcs buffer size accordingly). - Reslice pcs to the valid portion, looks like we missed that before; possible this was the "real" fix? - Change the list of file names that we skip. We were already using CallersFrames before the fix. The Go runtime does the right thing. > It does seem to in my local tests with up-to-date Go; i tried some toy examples and checked that functions really were being inlined. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAMhR0U1DtH_HLPFDO%2BRPT1xU0SxynoP_63uNE%2BzJ%2BES9wX%3D2Xg%40mail.gmail.com.
