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
Prof Brian Ripley
2009-Mar-06 23:20 UTC
[Rd] Fix for foreign package segfault on Solaris 10 Intel
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