Re: pkg/50772 perl and check_interpreter

[David Holland <dholland-pbugs%netbsd.org@localhost>]

The following reply was made to PR pkg/50772; it has been noted by GNATS.

From: David Holland <dholland-pbugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: pkg/50772 perl and check_interpreter
Date: Sat, 19 Nov 2016 17:32:54 +0000

 On Fri, Nov 18, 2016 at 12:25:01PM +0000, Stephen Borrill wrote:
  >  A few notes:
  >  
  >  Problem is not 100% reproducible. I expect this is depend on the order 
  >  that the link names are returned when looked up. On two different 
  >  systems:
 
 I was about to say I can't reproduce it at all, except after trying
 all my machines I found one that does... which isn't any different
 from the others.
 
 Using ktrace shows that it's is getting it by calling readlink on
 /proc/curproc/exe. It is a namecache issue (but not a readily fixable
 one) that /proc/curproc/exe returns an arbitrary name for the file and
 not the one used to open it.
 
 It's a bug in perl (or maybe an error in handling linux-specific
 logic) that it is using this information.
 
 One can reproduce the behavior fairly easily without perl:
 
    --- x.c ---
 #include <stdio.h>
 #include <unistd.h>
 #include <limits.h>
 #include <assert.h>
 #include <err.h>
 
 int
 main(void)
 {
         char buf[PATH_MAX+1];
         ssize_t len;
 
         len = readlink("/proc/curproc/exe", buf, sizeof(buf) - 1);
         if (len == -1) {
                 err(1, "readlink: /proc/curproc/exe");
         }
         assert(len < sizeof(buf));
         buf[len] = 0;
         printf("%s\n", buf);
         return 0;
 }
    ------
 
 % gcc -Wall x.c -o x
 % ./x
 /tmp/foo/x
 % ln x y
 % ./x
 /tmp/foo/x
 % ./y
 /tmp/foo/y
 % ./x
 /tmp/foo/y
 % 
 
 although the exact behavior will depend on how the namecache hashes
 the names you use.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost