Re: [Rd] R uses private function in libc (PR#9107)

From: <quanah_at_stanford.edu>
Date: Fri 28 Jul 2006 - 17:35:18 GMT

--On Friday, July 28, 2006 9:23 AM +0100 Prof Brian Ripley <ripley@stats.ox.ac.uk> wrote:

> On Fri, 28 Jul 2006, quanah@stanford.edu wrote:
>
>> Full_Name: Quanah Gibson-Mount
>> Version: 2.3.0, 2.3.1
>> OS: Linux
>
> That's not adequate information: see below.
>
>> Submission from: (NULL) (171.66.155.86)
>>
>>
>> libc used to export the symbol:
>>
>> __libc_stack_end;
>>
>> however, newer versions of libc no longer export it. R has some serious
>
> Please tell us what these `newer versions of libc' are.
>> g<libc does on e.g. 2.3.6 and 2.4, which is AFAICS current.
>
>> problems around this, because the code has:
>>
>> # ifdef linux
>> extern void * __libc_stack_end;
>> # endif
>>
>>
>> and
>>
>> # if defined(linux)
>> R_CStackStart = (uintptr_t) __libc_stack_end;
>> # elif defined(HAVE_KERN_USRSTACK)
>>
>>
>> in r-2.3.1/src/unix/system.c
>>
>> This code needs to be fixed. It is causing all sorts of problems when
>> trying to run R across multiple systems with different libc versions.
>
> What are the 'all sorts of problems'? It seems they are affecting no one
> else, and R is very widely used on Linux systems. So there is nothing
> here we can reproduce.

Well, here is a little background:

At Stanford, we build software and then make it available to campus via a distributed file system (AFS in our case). In building "R" for our new 64-bit Linux tree, we encountered this issue after building R on our 64-bit Debian Sarge system, which has libc version 2.3.2, and does export __libc_stack_end, although it is marked private, as it should be:

readelf -s /lib/libc.so.6 | grep __libc_stack_end

  1. 0000000000000000 8 OBJECT GLOBAL DEFAULT UND __libc_stack_end@GLIBC_PRIVATE (9)

After I released the build to campus, we immediately got reports that it didn't work on other systems, and finally tracked that down to the newer versions of libc on those systems:

bramble01:~> readelf -s /lib/libc.so.6 | grep __libc_stack_end bramble01:~> ldd --version
ldd (GNU libc) 2.3.6

yen4:~> readelf -s /lib/libc.so.6 | grep __libc_stack_end   2148: 00000000 4 OBJECT GLOBAL DEFAULT UND __libc_stack_end@GLIBC_2.1 (22)
  6010: 00000000 4 OBJECT GLOBAL DEFAULT UND __libc_stack_end@@GLIBC_2 yen4:~> ldd --version
ldd (GNU libc) 2.3.4

When running "R" on either the bramble or yen systems, the error one gets is:

yen4:~> R
/usr/pubsw/lib/R/2.3.1/R/bin/exec/R: relocation error: /usr/pubsw/lib/R/2.3.1/R/bin/exec/R: symbol __libc_stack_end, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference

bramble01:~> R
/usr/pubsw/lib/R/2.3.1/R/bin/exec/R: relocation error: /usr/pubsw/lib/R/2.3.1/R/bin/exec/R: symbol __libc_stack_end, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference

For now, I've managed to get around this by patching R thusly:

cat libc
--- r-2.3.1/src/unix/system.c.orig 2006-07-27 17:42:10.000000000 -0700 +++ r-2.3.1/src/unix/system.c 2006-07-27 17:46:42.000000000 -0700 @@ -117,9 +117,9 @@

 #  include <sys/time.h>
 # endif
 # include <sys/resource.h>
-# ifdef linux

+/* # ifdef linux
 extern void * __libc_stack_end;
-# endif
+# endif */
 # ifdef HAVE_KERN_USRSTACK
 #  include <unistd.h>
 #  include <sys/types.h>
@@ -157,9 +157,10 @@
        lim2 = (unsigned long) rlim.rlim_max; /* Usually unlimited */
         R_CStackLimit = lim1 < lim2 ? lim1 : lim2;
     }

-#if defined(linux)
+/* #if defined(linux)

     R_CStackStart = (uintptr_t) __libc_stack_end;

-#elif defined(HAVE_KERN_USRSTACK)
+#elif defined(HAVE_KERN_USRSTACK) */
+#if defined(HAVE_KERN_USRSTACK)
     {
        /* Borrowed from mzscheme/gc/os_dep.c */
        int nm[2] = {CTL_KERN, KERN_USRSTACK};


In any case, as you can see, __libc_stack_end goes away completely by libc 2.3.6, and as noted in the follow-up I sent to this bug yesterday, the reasons one shouldn't use this symbol are quite clearly stated here:

<http://www.mail-archive.com/debian-glibc@lists.debian.org/msg28253.html>

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Received on Sat Jul 29 03:38:10 2006

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.1.8, at Fri 28 Jul 2006 - 18:27:34 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-help. Please read the posting guide before posting to the list.