Hide Forgot
Description of problem: When using --remote, some stap failures cause SIGSEGV on several architectures: i386, ppc, s390x. The easiest reproducer seems to be usage of nonexistent file: # stap --remote root@$SERVERS -v foobar Input file 'foobar' is empty or missing. Pass 1: parsed user script and 73 library script(s) using 22048virt/13280res/2380shr kb, in 230usr/10sys/245real ms. Pass 1: parse failed. Try again with another '--vp 1' option. Segmentation fault (core dumped) (SERVERS contains a legitimate --remote target: a compatible and ssh-accessible box) Version-Release number of selected component (if applicable): systemtap-1.4-6.el6_1.2 How reproducible: always Steps to Reproduce: 1. stap --remote root@$SERVERS -v foobar 2. 3. Actual results: SEGV Expected results: no SEGV Additional info: Does not happen on x86_64 Also, this seems to be fixed in current upstream systemtap. Filing this bug so we can track if it is fixed in 6.2.
I believe that commit abc15290 fixed this by adding a proper copy-constructor for systemtap_session. This commit is included in systemtap 1.5. Before that, some of the members were getting badly copied when we would clone for a target machine different than local. For bonus points, it appears that i686 targets always got cloned, because the remote "i686" was compared to the normalized local "i386" and deemed different. That's why x86_64 may not have this problem, because there aren't any variant arch names for x86_64. I suspect if you had used an x86_64 target with a different kernel version than local, it would also fail on 1.4. Anyway, commit ba0bd1be will make sure to normalize the arch name before a clone is attempted.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause The --remote did not have a proper copy-constructor for systemtap_session. Consequence SystemTap stap command would produce a SEGV andfail to build instrumentation when the --remote options was used for i686, ppc, and s390x. Fix Systemtap fixed the session code to properly copy kernel/arch information to avoid using implicit behavior for the --remote option. Result SystemTap stap command builds instrumentation when the --remote options is for i686, ppc, and s390x.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2011-1517.html