[Rd] Fix for foreign package segfault on Solaris 10 Intel

[Prof Brian Ripley]

Interesting, thanks.  So

1) This is a shared R library build (not the default, and AFAIR no one 
reporting this has mentioned that -- not you, for example) and

2) You have a third-party libintl.

One solution would seem to be to ask R to use the libintl in the 
sources by (I think) --with-included-gettext .

I'll look into modifying foreign, but the combination of 1) and 2) 
could apply to alomost any library on the system and hence any symbol 
name in any package.

It's odd that you have -L/usr/apps/cdat32/NetCDF/lib in there, another 
potential cause for problems.

On Fri, 6 Mar 2009, Jeff Long wrote:

> I built it several times with a variety of flags and compilers. Here's what 
> was used for the gcc3 build:
>
> /opt/csw/gcc3/bin/gcc -std=gnu99 -G -L/opt/sfw/lib -L/opt/csw/lib 
> -L/opt/local/lib -L/usr/apps/cdat32/NetCDF/lib -o foreign.so avl.o dbfopen.o 
> file-handle.o format.o init.o minitab.o pfm-read.o Rdbfread.o Rdbfwrite.o 
> R_systat.o SASxport.o sfm-read.o spss.o stataread.o 
> -L/admin/users/jwlong/R/src/R-2.8.1/lib -lR
>
> On my system, the main R shared library shows a dependency on libavl, and 
> hence so does foreign.so and the R binary:
>
> % ldd R
>        libR.so =>       /opt/local/lib/R/lib/libR.so
>        libRblas.so =>   /opt/local/lib/R/lib/libRblas.so
>        libc.so.1 =>     /lib/libc.so.1
>        libg2c.so.0 =>   /opt/csw/lib/libg2c.so.0
>        libm.so.2 =>     /lib/libm.so.2
>        libintl.so.8 =>  /opt/csw/lib/libintl.so.8
>        libreadline.so.4 =>      /opt/csw/lib/libreadline.so.4
>        libncurses.so.5 =>       /opt/csw/lib/libncurses.so.5
>        libnsl.so.1 =>   /lib/libnsl.so.1
>        libsocket.so.1 =>        /lib/libsocket.so.1
>        libdl.so.1 =>    /lib/libdl.so.1
>        libiconv.so.2 =>         /opt/csw/lib/libiconv.so.2
>        libm.so.1 =>     /lib/libm.so.1
>        libgcc_s.so.1 =>         /opt/csw/lib/libgcc_s.so.1
>        libsec.so.1 =>   /lib/libsec.so.1
>        libmp.so.2 =>    /lib/libmp.so.2
>        libmd.so.1 =>    /lib/libmd.so.1
>        libscf.so.1 =>   /lib/libscf.so.1
>        libavl.so.1 =>   /lib/libavl.so.1
>        libdoor.so.1 =>  /lib/libdoor.so.1
>        libuutil.so.1 =>         /lib/libuutil.so.1
>        libgen.so.1 =>   /lib/libgen.so.1
>
>
> Looking through these various shared libs, it looks like /lib/libsec.so.1 is 
> the one that pulls in libavl. And libintl is what pulls in libsec. And R 
> itself pulls in libintl.
>
> Jeff
>
>
> ==========================================
> At 11:20 PM +0000 3/6/09, Prof Brian Ripley wrote:
>> Can you show us the output you get from building foreign, and explain how 
>> it comes to be linked against libavl?  I get (SunStudio 12)
>> 
>> cc -xc99 -G -L/opt/csw/lib -o foreign.so R_systat.o Rdbfread.o Rdbfwrite.o 
>> SASxport.o avl.o dbfopen.o file-handle.o format.o init.o minitab.o 
>> pfm-read.o sfm-read.o spss.o stataread.o
>> 
>> and ldd library/foreign/libs/foreign.so reveals no dependencies (and the R 
>> binary is not linked against libavl either).
>> 
>> I can see that linking against libavl could cause problems, but have no 
>> idea why that might be happening.
>> 
>> 
>> On Fri, 6 Mar 2009, Jeff Long wrote:
>> 
>>> Like a couple of other posters in the past year, I was seeing R 2.8.1 
>>> segfault in the foreign package on my Solaris 10 Intel system:
>>>
>>>      > library(foreign)
>>>
>>>      *** caught segfault ***
>>>      address fe1d5c70, cause 'invalid permissions'
>>>
>>>      Traceback:
>>>           1: .C("spss_init", PACKAGE = "foreign")
>>>           2: fun(...)
>>> 
>>> This happened whether I built with gcc3, gcc4, or SunStudio 12.
>>> 
>>> Using pstack I found that the code was crashing in avl_create(). Using 
>>> truss I found that identically named functions in the Solaris 
>>> /lib/libavl.so.1 library were being used instead of the AVL functions 
>>> provided in avl.c in the foreign package. To verify, I replaced all of the 
>>> "avl_" and "AVL_" patterns in foreign/src/*.[ch] with "ravl_" and "RAVL_" 
>>> respectively. Once I made this change, loading the foreign package caused 
>>> no further problems.
>>> 
>>> An alternative workaround was a hack involving symlinks and 
>>> LD_LIBRARY_PATH, but that was not satisfactory. Since the foreign avl 
>>> functions are incompatible with the ones provided by the standard Sun 
>>> library, this approach has other potential gotchas.
>>> 
>>> FYI.
>>> 
>>> Jeff
>>> 
>>> ______________________________________________
>>> R-devel at r-project.org mailing list
>>> https:// stat.ethz.ch/mailman/listinfo/r-devel
>>> 
>> 
>> --
>> Brian D. Ripley,                  ripley at stats.ox.ac.uk
>> Professor of Applied Statistics,  http:// www. stats.ox.ac.uk/~ripley/
>> University of Oxford,             Tel:  +44 1865 272861 (self)
>> 1 South Parks Road,                     +44 1865 272866 (PA)
>> Oxford OX1 3TG, UK                Fax:  +44 1865 272595
>

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595