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

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).

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

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?

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.

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.

- 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

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
>