semantic error: multiple addresses for ...

Josh Stone jistone@redhat.com
Tue Aug 24 20:34:00 GMT 2010


On 08/24/2010 12:55 PM, Roland McGrath wrote:
> Off hand, I see two potential approaches:
> 
> 1. Pay attention to is_stmt.
>    I mentioned this earlier.  To consider this, we'd really need to find
>    some cases where the current code legitimately complains as in PR1306,
>    and check whether the is_stmt flags in that DWARF info are useful.

I'm not sure how to check is_stmt, but here's a reproducer at a similar
location to the original bug report.

kernel-2.6.33.8-149.fc13.x86_64  fs/open.c:
> 1047 long do_sys_open(int dfd, const char __user *filename, int flags, int mode)
> 1048 {
> 1049         char *tmp = getname(filename);
> 1050         int fd = PTR_ERR(tmp);
> 1051 
> 1052         if (!IS_ERR(tmp)) {
> 1053                 fd = get_unused_fd_flags(flags);
> 1054                 if (fd >= 0) {
> 1055                         struct file *f = do_filp_open(dfd, tmp, flags, mode, 0);
> 1056                         if (IS_ERR(f)) {
> 1057                                 put_unused_fd(fd);
> 1058                                 fd = PTR_ERR(f);
> 1059                         } else {
> 1060                                 fsnotify_open(f->f_path.dentry);
> 1061                                 fd_install(fd, f);
> 1062                         }
> 1063                 }
> 1064                 putname(tmp);
> 1065         }
> 1066         return fd;
> 1067 }

$ stap -L 'kernel.statement("do_sys_open@fs/open.c:1053")'
semantic error: multiple addresses for fs/open.c:1053 (try
fs/open.c:1051 or fs/open.c:1058)


> 2. Apply the current rule only when there are multiple hits in the same scope.
>    This seems probably safer than relying on is_stmt, though it's not clear.
>    This should fix the case I just reported, and ones like it, where the
>    multiple hits are in entirely different instances of the same source code.

Isn't it possible for a line to legitimately occur multiple times in the
same scope?  For example, a statement within an unrolled loop *should*
get multiple probes after all, right?

The funny thing is that the current rule is only applied for statement
probes on line numbers (see the use of need_single_match).  Function
probes with line numbers are allowed to have duplicates, probably for
the exact reason you're complaining about, that there may be multiple
inline instances.


Josh



More information about the Systemtap mailing list