Download raw body.
follow up on 'stacktrace_save_utrace() should be more robust'
follow up on 'stacktrace_save_utrace() should be more robust'
follow up on 'stacktrace_save_utrace() should be more robust'
On Sun, Jun 08, 2025 at 03:25:02PM +0200, Mark Kettenis wrote:
> > Date: Sun, 8 Jun 2025 15:10:52 +0200
> > From: Alexandr Nedvedicky <sashan@fastmail.net>
> >
> > Hello,
> >
> > this is a finishing touch to change which got committed two weeks ago [1].
> > The current code copies invalid stack frame. This tweak just discards it.
> >
> > OK to commit?
>
> I don't think this is right. It is perfectly possible to have a stack
> frame with a valid return address but a saved %rbp or %ebp that isn't
> a valid frame pointer because the compiler decided it didn't need one.
I did not know it can be the case. I took a sample of 3 or 4 binaries
and the testing done suggested that if frame points to invalid
address then I can safely assume the return address is also invalid.
>
> I think your userland tooling needs to be adjusted to handle this.
>
the btrace(8) currently handles that by trying to find symbol
for invalid address. If no symbol is found it jut prints the
return address without symbol.
My concern is cost. because to find invalid address is
syscall + uvm_map_lookup_entry(). and we do it for every
invalid return address found on stack. So if there is some
way to find/determine invalid return on the stack then this
will be more than welcomed.
thanks and
regards
sashan
follow up on 'stacktrace_save_utrace() should be more robust'
follow up on 'stacktrace_save_utrace() should be more robust'
follow up on 'stacktrace_save_utrace() should be more robust'