vfs tapset compilation error.

vfs tapset compilation error.

[Daniel Fishman]

Hello,

When trying to execute the following:

stap -v -e 'probe vfs.read {printf("read performed\n"); exit()}'

compilation fails:

Pass 1: parsed user script and 144 library script(s) using 91224virt/39148res/2120shr kb, in 290usr/20sys/316real ms.
WARNING: cross-file global variable reference to identifier '__devnames' at /usr/share//systemtap/tapset/vfs.stp:20:8 from: identifier '__devnames' at /usr/share/systemtap/tapset/vfs.stp:23:13
 source: 	if (dev in __devnames)
         	           ^
semantic error: unresolved type : identifier '__devnames' at /usr/share//systemtap/tapset/vfs.stp:20:8
        source: global __devnames
                       ^
Pass 2: analyzed script: 2 probe(s), 23 function(s), 3 embed(s), 1 global(s) using 323644virt/145452res/6872shr kb, in 1750usr/220sys/1971real ms.
Pass 2: analysis failed.  Try again with another '--vp 01' option.


Why __devnames's type cannot be resolved?

Thanks,
Daniel.

Re: vfs tapset compilation error.

[William Cohen]

On 01/23/2011 11:39 PM, Daniel Fishman wrote:
> 
> Hello,
> 
> When trying to execute the following:
> 
> stap -v -e 'probe vfs.read {printf("read performed\n"); exit()}'
> 
> compilation fails:
> 
> Pass 1: parsed user script and 144 library script(s) using 91224virt/39148res/2120shr kb, in 290usr/20sys/316real ms.
> WARNING: cross-file global variable reference to identifier '__devnames' at /usr/share//systemtap/tapset/vfs.stp:20:8 from: identifier '__devnames' at /usr/share/systemtap/tapset/vfs.stp:23:13
>  source: 	if (dev in __devnames)
>          	           ^
> semantic error: unresolved type : identifier '__devnames' at /usr/share//systemtap/tapset/vfs.stp:20:8
>         source: global __devnames
>                        ^
> Pass 2: analyzed script: 2 probe(s), 23 function(s), 3 embed(s), 1 global(s) using 323644virt/145452res/6872shr kb, in 1750usr/220sys/1971real ms.
> Pass 2: analysis failed.  Try again with another '--vp 01' option.
> 
> 
> Why __devnames's type cannot be resolved?
> 
> Thanks,
> Daniel.
> 

Hi Daniel,

This has worked on a number of machines I have tried it on; I am not sure what the problem is. Could you give a bit more information about the environment you are running systemtap in?  The following wiki page list the pieces of information that would be useful in describing the context:

http://sourceware.org/systemtap/wiki/HowToReportBugs

-Will

Re: vfs tapset compilation error.

[Daniel Fishman]

On Mon, 24 Jan 2011 17:05:17 -0500, William Cohen <wcohen@redhat.com> wrote:

>Could you give a bit more information about the environment you are running systemtap in?
>

Below is an output from stap-report. 

The kernel is from utrace repository 
(git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-utrace.git)

The last commmit on the branch at a time the kernel was compiled:
db08bfc2c3d1c2e3c5658f59ee10cf5dbe9de7b1.


##############--stap-report begin--##############

== stap -V ==
SystemTap translator/driver (version 1.3/0.147 non-git sources)
Copyright (C) 2005-2010 Red Hat, Inc. and others
This is free software; see the source for copying conditions.
enabled features: AVAHI LIBSQLITE3 NSS BOOST_SHARED_PTR TR1_UNORDERED_MAP
== which stap ==
/usr/bin/stap
== locate --regex '/stap(run)?$' | xargs ls -ald ==
-rwxr-xr-x 1 root root    11486473 2010-03-29 02:16 /opt/systemtap/bin/stap
---s--x--x 1 root root      171625 2010-03-29 02:16 /opt/systemtap/bin/staprun
-rwxr-xr-x 1 root root     1572416 2010-11-20 09:53 /usr/bin/stap
-rwsr-x--- 1 root stapusr    64688 2010-11-20 09:53 /usr/bin/staprun
== printenv | egrep '^PATH=|^LD_LIBRARY_PATH=|^SYSTEMTAP_.*=' ==
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/opt/bin
== gcc -v ==
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.4.4-14ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5) 
== uname -a ==
Linux laptop 2.6.37-utrace #4 SMP Sun Jan 16 08:12:50 IST 2011 x86_64 GNU/Linux
== dmesg | egrep 'stap|systemtap' | tail -n 10 ==
== cat /proc/cpuinfo | egrep 'processor|vendor_id|model name' ==
processor	: 0
vendor_id	: GenuineIntel
model name	: Intel(R) Core(TM)2 Duo CPU     T7250  @ 2.00GHz
processor	: 1
vendor_id	: GenuineIntel
model name	: Intel(R) Core(TM)2 Duo CPU     T7250  @ 2.00GHz
== dpkg --list | egrep 'systemtap|elfutils|kernel|gcc' | awk '{print $2,$3}' | sort ==
bcmwl-kernel-source 5.60.48.36+bdcom-0ubuntu5
crash 5.0.4-1ubuntu1
elfutils 0.147-2
gcc 4:4.4.4-1ubuntu2
gcc-4.4 4.4.4-14ubuntu5
gcc-4.4-base 4.4.4-14ubuntu5
gcc-4.4-doc 4.4.4-14ubuntu5
gcc-4.4-multilib 4.4.4-14ubuntu5
gcc-4.5 4.5.1-7ubuntu2
gcc-4.5-base 4.5.1-7ubuntu2
gcc-4.5-doc 4.5.1-7ubuntu2
gcc-doc 4:4.4.4-1ubuntu2
gcc-multilib 4:4.4.4-1ubuntu2
kerneloops-daemon 0.12+git20090217-1ubuntu9
kernel-package 12.033
kernel-wedge 2.63ubuntu2
lib32gcc1 1:4.5.1-7ubuntu2
libaio1 0.3.107-7ubuntu1
libapm1 3.2.2-14
libdrm2 2.4.21-1ubuntu2.1
libdrm-dev 2.4.21-1ubuntu2.1
libdrm-intel1 2.4.21-1ubuntu2.1
libdrm-nouveau1 2.4.21-1ubuntu2.1
libdrm-radeon1 2.4.21-1ubuntu2.1
libgcc1 1:4.5.1-7ubuntu2
libkms1 2.4.21-1ubuntu2.1
linux-doc 2.6.35-24.42
linux-firmware 1.38.2
linux-generic 2.6.35.23.25
linux-headers-2.6.35-23 2.6.35-23.41
linux-headers-2.6.35-23-generic 2.6.35-23.41
linux-headers-2.6.37-utrace 2.6.37-utrace-10.00.Custom
linux-headers-generic 2.6.35.23.25
linux-image-2.6.35-23-generic 2.6.35-23.41
linux-image-2.6.37-utrace 2.6.37-utrace-10.00.Custom
linux-image-2.6.37-utrace-dbg 2.6.37-utrace-10.00.Custom
linux-image-generic 2.6.35.23.25
linux-manual-2.6.37-utrace 2.6.37-utrace-10.00.Custom
module-init-tools 3.12-1ubuntu2
powernowd 1.00-1ubuntu5
systemtap 1.3-1ubuntu0.1
systemtap-common 1.3-1ubuntu0.1
systemtap-doc 1.3-1ubuntu0.1
systemtap-runtime 1.3-1ubuntu0.1
udev 162-2.2
== egrep 'PROBE|TRACE|MARKER|_DEBUG_' /lib/modules/2.6.37-utrace/build/.config | grep -v not.set | sort | fmt -w 80 ==
CONFIG_AIC79XX_DEBUG_ENABLE=y CONFIG_AIC79XX_DEBUG_MASK=0
CONFIG_AIC7XXX_DEBUG_ENABLE=y CONFIG_AIC7XXX_DEBUG_MASK=0
CONFIG_ARCH_CPU_PROBE_RELEASE=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_BLK_DEV_IO_TRACE=y CONFIG_CAN_PM_TRACE=y CONFIG_CAPI_TRACE=y
CONFIG_CB710_DEBUG_ASSUMPTIONS=y CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_FS=y CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_MEMORY_INIT=y CONFIG_DEBUG_RODATA=y
CONFIG_DYNAMIC_FTRACE=y CONFIG_FTRACE_MCOUNT_RECORD=y CONFIG_FTRACE_NMI_ENTER=y
CONFIG_FTRACE_SYSCALLS=y CONFIG_FTRACE=y CONFIG_FUNCTION_GRAPH_TRACER=y
CONFIG_FUNCTION_TRACER=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_TRACER=y
CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y CONFIG_HAVE_FTRACE_NMI_ENTER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_MMIOTRACE_SUPPORT=y CONFIG_HAVE_OPTPROBES=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y CONFIG_KPROBE_EVENT=y CONFIG_KPROBES=y
CONFIG_KRETPROBES=y CONFIG_MMIOTRACE=y CONFIG_MTD_DOCPROBE_ADDRESS=0
CONFIG_MTD_DOCPROBE=m CONFIG_MTD_GEN_PROBE=m CONFIG_MTD_JEDECPROBE=m
CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADDRESS=0 CONFIG_MTD_QINFO_PROBE=m
CONFIG_NET_DCCPPROBE=m CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NET_SCTPPROBE=m CONFIG_NET_TCPPROBE=m CONFIG_NOP_TRACER=y
CONFIG_OCFS2_DEBUG_MASKLOG=y CONFIG_OPTPROBES=y CONFIG_PM_TRACE_RTC=y
CONFIG_PM_TRACE=y CONFIG_PNP_DEBUG_MESSAGES=y CONFIG_SCHED_TRACER=y
CONFIG_SCSI_LPFC_DEBUG_FS=y CONFIG_STACK_TRACER=y CONFIG_STACKTRACE_SUPPORT=y
CONFIG_STACKTRACE=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_TRACEPOINTS=y
CONFIG_TRACER_MAX_TRACE=y CONFIG_USER_STACKTRACE_SUPPORT=y CONFIG_UTRACE=y
CONFIG_WIMAX_DEBUG_LEVEL=8 CONFIG_WIMAX_I2400M_DEBUG_LEVEL=8

##############--stap-report end--##############

Re: vfs tapset compilation error.

[Mark Wielaard]

On Mon, 2011-01-24 at 06:39 +0200, Daniel Fishman wrote:
> When trying to execute the following:
> 
> stap -v -e 'probe vfs.read {printf("read performed\n"); exit()}'
> 
> compilation fails:
> 
> Pass 1: parsed user script and 144 library script(s) using 91224virt/39148res/2120shr kb, in 290usr/20sys/316real ms.
> WARNING: cross-file global variable reference to identifier '__devnames' at /usr/share//systemtap/tapset/vfs.stp:20:8 from: identifier '__devnames' at /usr/share/systemtap/tapset/vfs.stp:23:13
>  source: 	if (dev in __devnames)
>          	           ^

I am not sure if this is related, or that the warning message is just
confusing. We should probably fix that either way as soon as we figure
out what is really going on. Note that it does refer to the same file,
but one has a double slash in it:
  at /usr/share//systemtap/tapset/vfs.stp:20:8
from /usr/share/systemtap/tapset/vfs.stp:23:13

Was this systemtap build from source and then installed over the system
installed systemtap instance? Maybe that explains the next error,
although I don't really understand how/why.

> semantic error: unresolved type : identifier '__devnames' at /usr/share//systemtap/tapset/vfs.stp:20:8
>         source: global __devnames
>                        ^
> Pass 2: analyzed script: 2 probe(s), 23 function(s), 3 embed(s), 1 global(s) using 323644virt/145452res/6872shr kb, in 1750usr/220sys/1971real ms.
> Pass 2: analysis failed.  Try again with another '--vp 01' option.
> 
> 
> Why __devnames's type cannot be resolved?
> 
> Thanks,
> Daniel.

Re: vfs tapset compilation error.

[Mark Wielaard]

On Tue, 2011-01-25 at 12:38 +0100, Mark Wielaard wrote:
> On Mon, 2011-01-24 at 06:39 +0200, Daniel Fishman wrote:
> > When trying to execute the following:
> > 
> > stap -v -e 'probe vfs.read {printf("read performed\n"); exit()}'
> > 
> > compilation fails:
> > 
> > Pass 1: parsed user script and 144 library script(s) using 91224virt/39148res/2120shr kb, in 290usr/20sys/316real ms.
> > WARNING: cross-file global variable reference to identifier '__devnames' at /usr/share//systemtap/tapset/vfs.stp:20:8 from: identifier '__devnames' at /usr/share/systemtap/tapset/vfs.stp:23:13
> >  source: 	if (dev in __devnames)
> >          	           ^
> 
> I am not sure if this is related, or that the warning message is just
> confusing. We should probably fix that either way as soon as we figure
> out what is really going on. Note that it does refer to the same file,
> but one has a double slash in it:
>   at /usr/share//systemtap/tapset/vfs.stp:20:8
> from /usr/share/systemtap/tapset/vfs.stp:23:13

Just in case, could you try this hack to make sure the file names the
parse sees are always canonical?

commit 3bc15a1a0ac1de5b2196c45c307c32b976560d82
Author: Mark Wielaard <mjw@redhat.com>
Date:   Tue Jan 25 13:00:40 2011 +0100

    Make sure the file name the parser sees are canonical.

diff --git a/parse.cxx b/parse.cxx
index 2f6b2aa..b15f304 100644
--- a/parse.cxx
+++ b/parse.cxx
@@ -195,7 +195,8 @@ parser::parser (systemtap_session& s, istream& i, bool p):
 
 parser::parser (systemtap_session& s, const string& fn, bool p):
   session (s),
-  input_name (fn), free_input (new ifstream (input_name.c_str(), ios::in)),
+  input_name (canonicalize_file_name (fn.c_str())),
+  free_input (new ifstream (input_name.c_str(), ios::in)),
   input (* free_input, input_name, s), privileged (p),
   context(con_unknown), systemtap_v_seen(0), last_t (0), next_t (0), num_errors
 { }

Re: vfs tapset compilation error.

[Frank Ch. Eigler]

Daniel Fishman <quantera@gmail.com> writes:

> [...]
> WARNING: cross-file global variable reference to identifier '__devnames' at /usr/share//systemtap/tapset/vfs.stp:20:8 from: identifier '__devnames' at /usr/share/systemtap/tapset/vfs.stp:23:13
> semantic error: unresolved type : identifier '__devnames' at /usr/share//systemtap/tapset/vfs.stp:20:8
> [...]

The weird thing here is the double-slash in some places
(/usr/share//systemtap).  Is it coming from some personal environment
variable, or an artifact of a hand-built copy?

- FChE

Re: vfs tapset compilation error.

[Daniel Fishman]

On Tue, 25 Jan 2011 07:42:49 -0500, fche@redhat.com (Frank Ch. Eigler) wrote:

>The weird thing here is the double-slash in some places
>(/usr/share//systemtap).  Is it coming from some personal environment
>variable, or an artifact of a hand-built copy?

Your note gave me an idea where to look, and I found a way to reproduce
the problem.

Indeed the cause of the problem is an environment variable XDG_DATA_DIRS 
when one of it's path elements points to a location with directory 
systemtap/tapset (this variable started to be used for tapset path searching 
as a result of bug #11455).

Still not clear to me why this can cause an error, but on my machine the 
problem is reproducable with the latest systemtap from the repository.

Note that there seems to be an important difference between systemtap 1.3
and the one from repository: for 1.3, error occurs even if XDG_DATA_DIRS
search path contains a default search path:

Searched "/usr/share//systemtap/tapset/x86_64/*.stp", found 3
Searched "/usr/share//systemtap/tapset/*.stp", found 69
Searched "/usr/share/systemtap/tapset/x86_64/*.stp", found 3
Searched "/usr/share/systemtap/tapset/*.stp", found 69

For systemtap from repository this won't cause error - it just says something
like:

Searched "/usr/share//systemtap/tapset/x86_64/*.stp", found 3 processed 3
Searched "/usr/share//systemtap/tapset/*.stp", found 69 processed 69
Searched "/usr/share/systemtap/tapset/x86_64/*.stp", found 3 processed 0
Searched "/usr/share/systemtap/tapset/*.stp", found 69 processed 0

The problem occurs only if XDG_DATA_DIRS points to the same tapsets but in
a directory different from default search path. Then identical tapsets 
processed twice - once for each search path.

Can please somebody confirm that the problem reproduces elsewhere so
that I would open a new bug?

Re: vfs tapset compilation error.

[Daniel Fishman]

On Tue, 25 Jan 2011 13:04:29 +0100, Mark Wielaard <mjw@redhat.com> wrote:

>Just in case, could you try this hack to make sure the file names the
>parse sees are always canonical?

The problem occurs even if there is no double slashes. The additional
slash is due to the fact that XDG_DATA_DIRS was set to /usr/share/
(see my other reply), but the problem occurs when XDG_DATA_DIRS is 
set to /usr/share and there are no double slashes.

Re: vfs tapset compilation error.

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

On Tue, 2011-01-25 at 23:58 +0200, Daniel Fishman wrote:
> On Tue, 25 Jan 2011 13:04:29 +0100, Mark Wielaard <mjw@redhat.com> wrote:
> 
> >Just in case, could you try this hack to make sure the file names the
> >parse sees are always canonical?
> 
> The problem occurs even if there is no double slashes. The additional
> slash is due to the fact that XDG_DATA_DIRS was set to /usr/share/
> (see my other reply), but the problem occurs when XDG_DATA_DIRS is 
> set to /usr/share and there are no double slashes.

Aha, thanks. That makes sense. I am testing the following patch, which
should make sure all paths added to the include path are unique.

If you could also try it, that would be help.

Thanks,

Mark

[-- Attachment #2: 0001-Make-sure-all-elements-of-the-include-path-are-uniqu.patch --]
[-- Type: text/x-patch, Size: 2684 bytes --]

From 933705ea50ec6576f5b1ea5919a1482287b875b3 Mon Sep 17 00:00:00 2001
From: Mark Wielaard <mjw@redhat.com>
Date: Tue, 25 Jan 2011 23:40:22 +0100
Subject: [PATCH] Make sure all elements of the include path are unique.

---
 session.cxx |   29 +++++++++++++++++++++++------
 1 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/session.cxx b/session.cxx
index a79b771..6471338 100644
--- a/session.cxx
+++ b/session.cxx
@@ -20,6 +20,7 @@
 #include "util.h"
 #include "git_version.h"
 
+#include <algorithm>
 #include <cerrno>
 #include <cstdlib>
 
@@ -143,18 +144,32 @@ systemtap_session::systemtap_session ():
     tokenize(s_p1, dirs, ":");
     for(vector<string>::iterator i = dirs.begin(); i != dirs.end(); ++i)
     {
-      include_path.push_back(*i + "/systemtap/tapset");
+      string path = canonicalize_file_name ((*i + "/systemtap/tapset").c_str ());
+      if (find (include_path.begin (), include_path.end (), path)
+          == include_path.end ())
+        {
+          if (include_arg_start == -1)
+            include_arg_start = include_path.size ();
+          include_path.push_back(path);
+        }
     }
   }
 
   const char* s_p = getenv ("SYSTEMTAP_TAPSET");
   if (s_p != NULL)
   {
-    include_path.push_back (s_p);
+    string path = canonicalize_file_name (s_p);
+    if (find (include_path.begin (), include_path.end (), path)
+        == include_path.end ())
+      include_path.push_back (path);
   }
   else
   {
-    include_path.push_back (string(PKGDATADIR) + "/tapset");
+    string path = canonicalize_file_name ((string(PKGDATADIR)
+                                           + "/tapset").c_str ());
+    if (find (include_path.begin (), include_path.end (), path)
+        == include_path.end ())
+      include_path.push_back (path);
   }
 
   const char* s_r = getenv ("SYSTEMTAP_RUNTIME");
@@ -465,6 +480,7 @@ systemtap_session::parse_cmdline (int argc, char * const argv [])
       if (grc < 0)
         break;
       bool push_server_opt = false;
+      string path;
       switch (grc)
         {
         case 'V':
@@ -520,9 +536,10 @@ systemtap_session::parse_cmdline (int argc, char * const argv [])
         case 'I':
 	  if (client_options)
 	    client_options_disallowed += client_options_disallowed.empty () ? "-I" : ", -I";
-	  if (include_arg_start == -1)
-	    include_arg_start = include_path.size ();
-          include_path.push_back (string (optarg));
+          path = canonicalize_file_name (optarg);
+          if (find (include_path.begin (), include_path.end (), path)
+              == include_path.end ())
+            include_path.push_back(path);
           break;
 
         case 'd':
-- 
1.7.3.5

Re: vfs tapset compilation error.

[Mark Wielaard]

On Tue, 2011-01-25 at 23:44 +0100, Mark Wielaard wrote:
> On Tue, 2011-01-25 at 23:58 +0200, Daniel Fishman wrote:
> > On Tue, 25 Jan 2011 13:04:29 +0100, Mark Wielaard <mjw@redhat.com> wrote:
> > 
> > >Just in case, could you try this hack to make sure the file names the
> > >parse sees are always canonical?
> > 
> > The problem occurs even if there is no double slashes. The additional
> > slash is due to the fact that XDG_DATA_DIRS was set to /usr/share/
> > (see my other reply), but the problem occurs when XDG_DATA_DIRS is 
> > set to /usr/share and there are no double slashes.
> 
> Aha, thanks. That makes sense. I am testing the following patch, which
> should make sure all paths added to the include path are unique.
> 
> If you could also try it, that would be help.

Although it seems my patch works, and we do scan fewer files if an
include dir happens to be included multiple times, I am still a little
confused how this can happen. This issue should already have been dealt
with through: http://sourceware.org/bugzilla/show_bug.cgi?id=11949

Do you have the following commit included in your build?

commit ad7c8e4393af112099a0ab3c54e3b49056ef6289
Author: Frank Ch. Eigler <fche@elastic.org>
Date:   Thu Aug 26 18:30:28 2010 -0400

    PR11949: duplicate-eliminate tapset files
    
    * main.cxx (passes_0_4): Bypass tapset script files already parsed,
      based upon device/inode matching.

Thanks,

Mark

Re: vfs tapset compilation error.

[Josh Stone]

On 01/25/2011 03:59 PM, Mark Wielaard wrote:
> Although it seems my patch works, and we do scan fewer files if an
> include dir happens to be included multiple times, I am still a little
> confused how this can happen. This issue should already have been dealt
> with through: http://sourceware.org/bugzilla/show_bug.cgi?id=11949
> 
> Do you have the following commit included in your build?
> 
> commit ad7c8e4393af112099a0ab3c54e3b49056ef6289
> Author: Frank Ch. Eigler <fche@elastic.org>
> Date:   Thu Aug 26 18:30:28 2010 -0400
> 
>     PR11949: duplicate-eliminate tapset files

Daniel's stap-report says version 1.3, which came out in July.  We went
a long time between releases for 1.4, which finally included this fix.
And see his other mail which shows that stap.git indeed processes
nothing from the duplicate path.

We can still have a problem though, e.g. if XDG_DATA_DIRS=/usr/share,
but you're trying to run /usr/local/bin/stap (or /opt, etc.)

I think we need a way to mark that certain paths should only be included
via the main tapset path (PREFIX/systemtap/tapset or SYSTEMTAP_TAPSET).
 There are many means, but perhaps something like just an empty
".systemtap_tapset" file could indicate that this path should not be
searched via -I or XDG_DATA_DIRS.

You'd have to manually add this to old installations in order to get
newer staps to ignore such paths, but at least this is a possible
workaround.  Any other ideas?


Josh

Re: vfs tapset compilation error.

[Mark Wielaard]

On Tue, 2011-01-25 at 17:10 -0800, Josh Stone wrote:
> I think we need a way to mark that certain paths should only be included
> via the main tapset path (PREFIX/systemtap/tapset or SYSTEMTAP_TAPSET).
>  There are many means, but perhaps something like just an empty
> ".systemtap_tapset" file could indicate that this path should not be
> searched via -I or XDG_DATA_DIRS.
> 
> You'd have to manually add this to old installations in order to get
> newer staps to ignore such paths, but at least this is a possible
> workaround.  Any other ideas?

Good idea. We could just use an existing system tapset file like
null.stp for this. Or if you are afraid someone might put such a file in
their own tapset include dir, use something a little more obscure like
<arch>/nd_syscalls.stp.

Cheers,

Mark

Re: vfs tapset compilation error.

[Daniel Fishman]

On Wed, 26 Jan 2011 12:08:04 +0100, Mark Wielaard <mjw@redhat.com> wrote:

>Good idea. We could just use an existing system tapset file like
>null.stp for this. Or if you are afraid someone might put such a file in
>their own tapset include dir, use something a little more obscure like
><arch>/nd_syscalls.stp.

Is the problem exists only in case of system paths? What would happen if
user has private tapset (or maybe even just identically named function
in different private tapsets) that could be found in multiple locations on 
XDG_DATA_DIRS paths?

Re: vfs tapset compilation error.

[Mark Wielaard]

> >Good idea. We could just use an existing system tapset file like
> >null.stp for this. Or if you are afraid someone might put such a file
> >in
> >their own tapset include dir, use something a little more obscure
> >like
> ><arch>/nd_syscalls.stp.
> 
> Is the problem exists only in case of system paths? What would happen
> if
> user has private tapset (or maybe even just identically named function
> in different private tapsets) that could be found in multiple
> locations on
> XDG_DATA_DIRS paths?

Frank raised a somewhat similar issue in this bug report:
http://sourceware.org/bugzilla/show_bug.cgi?id=12443
Although that is about application/package installed tapsets in the
"system path".

But in general having multiple somewhat identical private tapsets on
the include path just doesn't work. Since as you say if you have
identical named functions they will clash. So, I do think it is only
a real problem with tapset in "system" dirs (and as Frank pointed out
if you put a "private" tapset in such a dir).

Cheers,

Mark

Re: vfs tapset compilation error.

[Sateesh]

Daniel Fishman <quantera <at> gmail.com> writes:

> The problem occurs only if XDG_DATA_DIRS points to the same tapsets but in
> a directory different from default search path. Then identical tapsets 
> processed twice - once for each search path.
> 
> Can please somebody confirm that the problem reproduces elsewhere so
> that I would open a new bug?
> 
> 

The problem is indeed seen if $(stap -v -e 'probe vfs.read {printf("read
performed\n"); exit()}') is run as a non-root user, but is not a problem if run
as a root user