View Bug Activity | Format For Printing
Bug #3050 may have been closed but the bug did not stay dead. The same code on current fc7 kernels gives the usual single line of backtrace info. The kernel backtracer always seems to do a better job than the code in the runtime. There are several problems with the code. It uses unprotected dereference code like "*stack++", even though the stack values are not completely reliable. It does not know how to distinguish between alternative stacks such as the trap stack, the normal kernel stack, or whatever happens to come in pt_regs. This is key because backtrace() should from both kprobes and from ordinary hook calls such as timers, begin/end, and markers. The backtrace() function should not include the "Inexact backtrace:" string, as this breaks subsequent tokenizing with print_stack().
Further information... an analogous problem exists even on i386. Here, a stack traceback from a kprobe includes a lot of the kprobes invocation path, but none actually from (above) the context of the int3 itself.
Created an attachment (id=1972) x86-64 backtracing fix patch This patch fixes this bug. AFAIK, the value (not the address) of rsp is specifying the original stack address on x86-64.
> This patch fixes this bug. > AFAIK, the value (not the address) of rsp is specifying the original stack > address on x86-64. Unfortunately, it's not so easy. Sometimes (kprobes versus other event sources?) the ®_SP value is more correct. We lack a convincing set of test cases either way. Would you mind collecting a set?
(In reply to comment #3) > > This patch fixes this bug. > > AFAIK, the value (not the address) of rsp is specifying the original stack > > address on x86-64. > > Unfortunately, it's not so easy. Sometimes (kprobes versus other > event sources?) the ®_SP value is more correct. We lack a convincing > set of test cases either way. Would you mind collecting a set? Could you tell me the actual example which the ®_SP value is more correct than REG_SP? And what sources can the systemtap use? I just know kprobe/kretprobe/timer/marker/profile.
Created an attachment (id=1982) enhance backtrace test This patch adds test cases of return probe and profile probe to the backtrace test.
(In reply to comment #4) > (In reply to comment #3) ... > > > > Unfortunately, it's not so easy. Sometimes (kprobes versus other > > event sources?) the ®_SP value is more correct. We lack a convincing > > set of test cases either way. Would you mind collecting a set? > > Could you tell me the actual example which the ®_SP value is more correct > than REG_SP? I don't know whether this is what Frank is thinking of, but... On i386, when you take an int3 trap and you're already in kernel mode, the CPU doesn't save the esp and ss registers. So the last two words (esp and xss) of the pt_regs struct that kprobes passes around actually contain the top two words of the pre-trap stack. So the pre-trap top-of-stack is ®s->esp. On x86_64, the CPU saves rsp and ss even if the trap happens in kernel mode, so the pre-trap top-of-stack is regs->rsp rather than ®s->rsp.
Many thanks - please commit the changes and the tests.
OK, the patch was committed.