llvm dev - Jul 2012 - [LLVMdev] [llvm-commits] Dealing with a corrupted /proc/self/exe link

Benjamin Kramer wrote:
> On 13.07.2012, at 09:46, Gabor Greif <gabor.greif at
alcatel-lucent.com> wrote:
> 
>> Hi all,
>>
>> I am in charge of the controlled introduction of clang into
>> our builds at my workplace. Since all our tools must run from
>> a ClearCase view for automatic dependency tracking, we have been
>> biten by a Linux bug, and readlink("/proc/self/exe", ...)
gives
>> nonsensical results. So we need to introduce a configure option
>> for disallowing this method of executable discovery (the other
>> one works well).
> 
> Interesting, can you describe the linux bug? Are the kernel devs aware of
it?
It is fixed in newer RHEL kernels (>=6). What I know is that this is a
ClearCase VFS-related bug that fails to do a reverse mapping to obtain
the logical pathname from the real (into the backing store of ClearCase)
one.

Here is a bug report:
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6189256>
> 
> We often had reports about /proc/self/exe not working (and thus clang
crashing)
> in chrooted environments. It is possible to mount /proc into the chroot but
this
> seems to be missing from many setups. The code in LLVM that uses
/proc/self/exe
> returns an empty string on error which confuses clang.
There is no empty string for me, and the returned string is a real object
(bytewise identical to the real thing) :

$ cd <into a dynamic view>
$ cp /bin/ls .
$ ls -l /proc/self/exe
lrwxrwxrwx 1 ggreif ocs 0 Jul 13 21:27 /proc/self/exe -> /bin/ls
$ ./ls -l /proc/self/exe
lrwxrwxrwx 1 ggreif ocs 0 Jul 13 21:27 /proc/self/exe ->
/vol/ocs_userviews25_13/ggreif-hc_stm-OCSnb28718.vws/.s/00056/800006ba4fdf647els

$ diff ./ls
/vol/ocs_userviews25_13/ggreif-hc_stm-OCSnb28718.vws/.s/00056/800006ba4fdf647els
<no diffs>

Unfortunately starting from the clang executable, there is no useful
directory structure to be discovered :-(
> 
> I don't really like having an autoconf switch for this as long as you
can determine
> whether the result from /proc/self/exe is valid. When you're adding a
fallback to
> Path.inc anyways, why not just try reading /proc/self/exe first, and if it
fails, use
> your fallback? That would also fix the chroot problem.
This is not a chroot problem. As shown above, I do not get a valid clang path
to manipulate and discover include directories, etc.

The other method in lib/Support/Unix/Path.inc (i.e. dladdr, realpath) works.

I still maintain that I need the configure option.

Cheers,

	Gabor

PS: removed llvm-commits from the CC: list.
> 
> - Ben
> 
>> Here is the patch:
>>
>>
>>
>> Index: autoconf/configure.ac
>>
==================================================================>> ---
autoconf/configure.ac       (revision 160127)
>> +++ autoconf/configure.ac       (working copy)
>> @@ -647,6 +647,20 @@
>> AC_DEFINE_UNQUOTED([ENABLE_TIMESTAMPS],$ENABLE_TIMESTAMPS,
>>                    [Define if timestamp information (e.g., __DATE__) is
allowed])
>>
>> +dnl Enable reading of the "/proc/self/exe" link.
>> +AC_ARG_ENABLE(proc-self-exe,
>> +  AS_HELP_STRING([--enable-proc-self-exe],
>> +                 [Enable reading of the "/proc/self/exe"
link (default is YES)]),,
>> +                 enableval=default)
>> +case "$enableval" in
>> +  yes) AC_SUBST(ENABLE_PROC_SELF_EXE,[1]) ;;
>> +  no)  AC_SUBST(ENABLE_PROC_SELF_EXE,[0]) ;;
>> +  default) AC_SUBST(ENABLE_PROC_SELF_EXE,[1]) ;;
>> +  *) AC_MSG_ERROR([Invalid setting for --enable-proc-self-exe. Use
"yes" or "no"]) ;;
>> +esac
>> +AC_DEFINE_UNQUOTED([ENABLE_PROC_SELF_EXE],$ENABLE_PROC_SELF_EXE,
>> +                   [Define if reading of the
"/proc/self/exe" link is allowed])
>> +
>> dnl Allow specific targets to be specified for building (or not)
>> TARGETS_TO_BUILD=""
>> AC_ARG_ENABLE([targets],AS_HELP_STRING([--enable-targets],
>>
>>
>> I'll commit after a LGTM.
>>
>> However before tweaking lib/Support/Unix/Path.inc I have to add a cmake
>> modification, which can be simply <always on>. Hints how to do
this are
>> welcome, but I guess I'll figure it out.
>>
>> So what do you think?
>>
>> Cheers,
>>
>> 	Gabor
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>

On 13.07.2012, at 21:39, Gabor Greif <gabor.greif at alcatel-lucent.com>
wrote:
> Benjamin Kramer wrote:
>> On 13.07.2012, at 09:46, Gabor Greif <gabor.greif at
alcatel-lucent.com> wrote:
>> 
>>> Hi all,
>>> 
>>> I am in charge of the controlled introduction of clang into
>>> our builds at my workplace. Since all our tools must run from
>>> a ClearCase view for automatic dependency tracking, we have been
>>> biten by a Linux bug, and readlink("/proc/self/exe", ...)
gives
>>> nonsensical results. So we need to introduce a configure option
>>> for disallowing this method of executable discovery (the other
>>> one works well).
>> 
>> Interesting, can you describe the linux bug? Are the kernel devs aware
of it?
> 
> It is fixed in newer RHEL kernels (>=6). What I know is that this is a
> ClearCase VFS-related bug that fails to do a reverse mapping to obtain
> the logical pathname from the real (into the backing store of ClearCase)
> one.
> 
> Here is a bug report:
> <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6189256>
> 
>> 
>> We often had reports about /proc/self/exe not working (and thus clang
crashing)
>> in chrooted environments. It is possible to mount /proc into the chroot
but this
>> seems to be missing from many setups. The code in LLVM that uses
/proc/self/exe
>> returns an empty string on error which confuses clang.
> 
> There is no empty string for me, and the returned string is a real object
> (bytewise identical to the real thing) :
> 
> $ cd <into a dynamic view>
> $ cp /bin/ls .
> $ ls -l /proc/self/exe
> lrwxrwxrwx 1 ggreif ocs 0 Jul 13 21:27 /proc/self/exe -> /bin/ls
> $ ./ls -l /proc/self/exe
> lrwxrwxrwx 1 ggreif ocs 0 Jul 13 21:27 /proc/self/exe ->
/vol/ocs_userviews25_13/ggreif-hc_stm-OCSnb28718.vws/.s/00056/800006ba4fdf647els
> 
> $ diff ./ls
/vol/ocs_userviews25_13/ggreif-hc_stm-OCSnb28718.vws/.s/00056/800006ba4fdf647els
> <no diffs>
> 
> Unfortunately starting from the clang executable, there is no useful
> directory structure to be discovered :-(
> 
>> 
>> I don't really like having an autoconf switch for this as long as
you can determine
>> whether the result from /proc/self/exe is valid. When you're adding
a fallback to
>> Path.inc anyways, why not just try reading /proc/self/exe first, and if
it fails, use
>> your fallback? That would also fix the chroot problem.
> 
> This is not a chroot problem. As shown above, I do not get a valid clang
path
> to manipulate and discover include directories, etc.
> 
> The other method in lib/Support/Unix/Path.inc (i.e. dladdr, realpath)
works.
> 
> I still maintain that I need the configure option.
Sorry for being mean, but this is a workaround for a bug in the linux kernel
that was
fixed years ago and is only visible when using an obscure revision control
system.

Also it requires rebuilding LLVM, so the fix isn't even helpful without
researching the
issue (if someone else hits it).

With this in mind I really don't see why this has to be in the public tree,
requiring
additions to two build systems. Can't you just apply the one-line-patch to
Path.inc
locally?

- Ben

On Fri, Jul 13, 2012 at 1:40 PM, Benjamin Kramer <benny.kra at
gmail.com>wrote:
>
> On 13.07.2012, at 21:39, Gabor Greif <gabor.greif at
alcatel-lucent.com>
> wrote:
>
> > Benjamin Kramer wrote:
> >> On 13.07.2012, at 09:46, Gabor Greif <gabor.greif at
alcatel-lucent.com>
> wrote:
> >>
> >>> Hi all,
> >>>
> >>> I am in charge of the controlled introduction of clang into
> >>> our builds at my workplace. Since all our tools must run from
> >>> a ClearCase view for automatic dependency tracking, we have
been
> >>> biten by a Linux bug, and readlink("/proc/self/exe",
...) gives
> >>> nonsensical results. So we need to introduce a configure
option
> >>> for disallowing this method of executable discovery (the other
> >>> one works well).
> >>
> >> Interesting, can you describe the linux bug? Are the kernel devs
aware
> of it?
> >
> > It is fixed in newer RHEL kernels (>=6). What I know is that this
is a
> > ClearCase VFS-related bug that fails to do a reverse mapping to obtain
> > the logical pathname from the real (into the backing store of
ClearCase)
> > one.
> >
> > Here is a bug report:
> > <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6189256>
> >
> >>
> >> We often had reports about /proc/self/exe not working (and thus
clang
> crashing)
> >> in chrooted environments. It is possible to mount /proc into the
chroot
> but this
> >> seems to be missing from many setups. The code in LLVM that uses
> /proc/self/exe
> >> returns an empty string on error which confuses clang.
> >
> > There is no empty string for me, and the returned string is a real
object
> > (bytewise identical to the real thing) :
> >
> > $ cd <into a dynamic view>
> > $ cp /bin/ls .
> > $ ls -l /proc/self/exe
> > lrwxrwxrwx 1 ggreif ocs 0 Jul 13 21:27 /proc/self/exe -> /bin/ls
> > $ ./ls -l /proc/self/exe
> > lrwxrwxrwx 1 ggreif ocs 0 Jul 13 21:27 /proc/self/exe ->
>
/vol/ocs_userviews25_13/ggreif-hc_stm-OCSnb28718.vws/.s/00056/800006ba4fdf647els
> >
> > $ diff ./ls
>
/vol/ocs_userviews25_13/ggreif-hc_stm-OCSnb28718.vws/.s/00056/800006ba4fdf647els
> > <no diffs>
> >
> > Unfortunately starting from the clang executable, there is no useful
> > directory structure to be discovered :-(
> >
> >>
> >> I don't really like having an autoconf switch for this as long
as you
> can determine
> >> whether the result from /proc/self/exe is valid. When you're
adding a
> fallback to
> >> Path.inc anyways, why not just try reading /proc/self/exe first,
and if
> it fails, use
> >> your fallback? That would also fix the chroot problem.
> >
> > This is not a chroot problem. As shown above, I do not get a valid
clang
> path
> > to manipulate and discover include directories, etc.
> >
> > The other method in lib/Support/Unix/Path.inc (i.e. dladdr, realpath)
> works.
> >
> > I still maintain that I need the configure option.
>
> Sorry for being mean, but this is a workaround for a bug in the linux
> kernel that was
> fixed years ago and is only visible when using an obscure revision control
> system.
>
> Also it requires rebuilding LLVM, so the fix isn't even helpful without
> researching the
> issue (if someone else hits it).
>
> With this in mind I really don't see why this has to be in the public
> tree, requiring
> additions to two build systems. Can't you just apply the one-line-patch
to
> Path.inc
> locally?

I agree, this patch as is doesn't belong in the tree...

However, I suspect that Clang already hase the capability to solve this
problem for you.

For context, we run Clang in a distributed build environment not dissimilar
to the one you are describing, and for us as well /proc/self/exe does not
really help us locate the Clang binary. There is a switch available
(-no-canonical-prefixes) which in conjunction with some other things should
use the value of argv[0] in main to locate the clang binary, not
/proc/self/exe or anything else.

Can you describe why it is that Clang is reading /proc/self/exe? We might
be able to change that in a principled way to support numerous different
filesystem layouts and scenarios where its results are correct but not
helpful for locating executable-relative directory structures.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120713/6f7dba55/attachment.html>