[BUG] Systemtap git master HEAD fails on Fedora 17 x86_64 (kernel 3.6.7)

[agentzh <agentzh at gmail dot com>]

Hello!

The recent git master HEAD of systemtap does not work at all on my Fedora 17:

    $ uname -a
    Linux w530 3.6.7-4.fc17.x86_64 #1 SMP Tue Nov 20 19:40:01 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux

I'm using the latest kernel from the official yum repository of Fedora 17.

The systemtap build is compiled from the latest git master HEAD
(commit 6b378b7c40b):

    $ gcc --version
    gcc (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2)
    Copyright (C) 2012 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    Even hello world does not work because "stap" quits at startup:

    $  ./configure --prefix=/opt/systemtap --disable-docs
--disable-publican --disable-refdocs && make -j8
    ...

    $ sudo make install
    ...

    $ PATH=/opt/systemtap/bin:$PATH stap --version
    Systemtap translator/driver (version 2.1/0.154, commit
release-2.0-108-g6b378b7)
    Copyright (C) 2005-2012 Red Hat, Inc. and others
    This is free software; see the source for copying conditions.
    enabled features: AVAHI LIBRPM LIBSQLITE3 NSS BOOST_SHARED_PTR
TR1_UNORDERED_MAP NLS

    $ PATH=/opt/systemtap/bin:$PATH stap -v -e 'probe begin {
println("hello") exit() }'

Yes, no output at all. Using strace to inspect it:

    $ PATH=/opt/systemtap/bin:$PATH strace stap -v -e 'probe begin {
println("hello") exit() }'
    ...
    brk(0x10e9000)                          = 0x10e9000
    read(3, "00000000\tacpi_unload_table_id\tvm"..., 8191) = 8191
    read(3, "EXPORT_SYMBOL\n0x00000000\tvb2_ioc"..., 8191) = 8191
    read(3, "0000\tunregister_sound_dsp\tsound/"..., 8191) = 1009
    read(3, "", 8191)                       = 0
    close(3)                                = 0
    open("/lib/modules/3.6.7-4.fc17.x86_64/build/System.map",
O_RDONLY) = -1 ENOENT (No such file or directory)
    open("/boot/System.map-3.6.7-4.fc17.x86_64", O_RDONLY) = -1 EACCES
(Permission denied)
    rt_sigprocmask(SIG_BLOCK, [HUP INT PIPE TERM], [], 8) = 0
    clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7f0420eccad0) = 9106
    rt_sigprocmask(SIG_BLOCK, [HUP INT PIPE TERM], [HUP INT PIPE TERM], 8) = 0
    rt_sigprocmask(SIG_SETMASK, [HUP INT PIPE TERM], NULL, 8) = 0
    wait4(9106, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 9106
    --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=9106,
si_status=0, si_utime=0, si_stime=0} ---
    rt_sigprocmask(SIG_BLOCK, [HUP INT PIPE TERM], [HUP INT PIPE TERM], 8) = 0
    rt_sigprocmask(SIG_SETMASK, [HUP INT PIPE TERM], NULL, 8) = 0
    rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
    exit_group(1)                           = ?
    +++ exited with 1 +++

It seems that SIGCHLD happens there.

Using the systemtap 2.0 release tarball works for me:

    $ PATH=/opt/systemtap20/bin:$PATH stap --version
    Systemtap translator/driver (version 2.0/0.154, non-git sources)
    Copyright (C) 2005-2012 Red Hat, Inc. and others
    This is free software; see the source for copying conditions.
    enabled features: AVAHI LIBRPM LIBSQLITE3 NSS BOOST_SHARED_PTR
TR1_UNORDERED_MAP NLS

    $ PATH=/opt/systemtap20/bin:$PATH stap -v -e 'probe begin {
println("hello") exit() }'
    Pass 1: parsed user script and 89 library script(s) using
202416virt/21940res/2852shr/19736data kb, in 90usr/20sys/450real ms.
    Pass 2: analyzed script: 1 probe(s), 1 function(s), 0 embed(s), 0
global(s) using 202944virt/22712res/2952shr/20264data kb, in
10usr/0sys/45real ms.
    Pass 3: translated to C into
"/tmp/stappbpQm5/stap_3de736424383f206ac40c9667b3049ae_963_src.c"
using 202944virt/23016res/3212shr/20264data kb, in 0usr/0sys/0real ms.
    Pass 4: compiled C into
"stap_3de736424383f206ac40c9667b3049ae_963.ko" in
1120usr/330sys/1596real ms.
    Pass 5: starting run.
    hello
    Pass 5: run completed in 10usr/20sys/348real ms.

If you need more information to fix this, please let me know.

I really hope that the git master HEAD can be a little more stable ;)

Best regards,
-agentzh