Description of problem:

There is a possibility of crashing the kernel when creating a backtrace in a stap script. This is caused by a kernel backport of the dump_stack code that now takes a new argument which wasn't filled in by the systemtap runtime code.

Version-Release number of selected component (if applicable):

systemtap-1.2-3.el6.x86_64

How reproducible:

50%. It depends on the normal systemtap unwinder failing (for example because it cannot access some memory needed), then the fallback kernel dump_stack code might be called with a not fully filled in stacktrace_ops struct (since the backport introduced a new stack_walk field we don't expect in kernel version < 2.6.33), which might lead to the kernel jumping to a random address.

Steps to Reproduce:
1. Run context.exp testcase (make installcheck RUNTESTFLAGS=context.exp)
  
Actual results:

Kernel crash with OOPs.

Expected results:

No crashing kernel, but passing testcase.

Additional info:

Fixed upstream

commit c265cd259a82542abf290a6aeb058056d6c18b73
Author: Mark Wielaard <mjw@redhat.com>
Date:   Thu Jun 3 11:26:17 2010 +0200

    Replace walk_stack field version guard with autoconf test.
    
    The test for whether or not to assign print_context_stack to the
    walk_stack stacktrace_ops field depended on the kernel version.
    Replace with a proper runtime/autoconf test to make sure the field
    always gets assigned when available.
    
    * buildrun.cxx (compile_pass): Add output for STAP_CONF_WALK_STACK.
    * runtime/autoconf-walk-stack.c: New test.
    * runtime/stack.c (print_stack_ops): Assign walk_stack field
      print_context_stack depending on STAP_CONF_WALK_STACK.