Hello, recently I discovered an issue by installing a new package from CRAN: `install.packages("roxygen2")` results in a segfault: ``` ... trying URL 'https://cran.r-project.org/src/contrib/brew_1.0-6.tar.gz' *** caught segfault *** address 0x7fffdfdfe000, cause 'invalid permissions' Traceback: 1: download.file(url, destfile, method, mode = "wb", ...) 2: doTryCatch(return(expr), name, parentenv, handler) 3: tryCatchOne(expr, names, parentenv, handlers[[1L]]) 4: tryCatchList(expr, classes, parentenv, handlers) 5: tryCatch(expr, error = function(e) { call <- conditionCall(e) if (!is.null(call)) { if (identical(call[[1L]], quote(doTryCatch))) call <- sys.call(-4L) dcall <- deparse(call)[1L] prefix <- paste("Error in", dcall, ": ") LONG <- 75L msg <- conditionMessage(e) sm <- strsplit(msg, "\n")[[1L]] w <- 14L + nchar(dcall, type = "w") + nchar(sm[1L], type = "w") if (is.na(w)) w <- 14L + nchar(dcall, type = "b") + nchar(sm[1L], type = "b") if (w > LONG) prefix <- paste0(prefix, "\n ") } else prefix <- "Error : " msg <- paste0(prefix, conditionMessage(e), "\n") .Internal(seterrmessage(msg[1L])) if (!silent && identical(getOption("show.error.messages"), TRUE)) { cat(msg, file = outFile) .Internal(printDeferredWarnings()) } invisible(structure(msg, class = "try-error", condition = e))}) 6: try(download.file(url, destfile, method, mode = "wb", ...)) 7: download.packages(pkgs, destdir = tmpd, available = available, contriburl = contriburl, method = method, type = "source", quiet = quiet, ...) 8: install.packages("roxygen2") ``` I tried to install various packages from CRAN. Segfault occurs after downloading a bunch of dependencies (there is not a certain dependency that throws this error). I tried the R package from the quarterly branch as well as the package from the latest branch without any luck. Does this affect more people? Are there any workarounds? Best
An upstream bug report has been submitted. https://stat.ethz.ch/pipermail/r-devel/2017-August/074726.html
CC some people that have shown recent interest in the math/R port.
I just installed "roxygen2" without a problem. R-3.4.1_3 with RBLAS=yes FLANG=yes
Could you confirm you're running 11.1-RELEASE or later?
Segfault on download through https might result from the mixup of base and port SSL libraries. You need to see if 'ldd /usr/local/bin/R' shows such mix.
running FreeBSD 11.1-STABLE r321380M
I'm running FreeBSD 11.1, too. I had no problems before upgrading to 11.1 but I haven't used R for one month. So it may as well possible that the problems occured with current quarterly branch. For me, ldd shows nothing strange: ``` $ ldd /usr/local/lib/R/bin/exec/R /usr/local/lib/R/bin/exec/R: libR.so => /usr/local/lib/R/lib/libR.so (0x800a00000) libRblas.so => /usr/local/lib/R/lib/libRblas.so (0x800fe9000) libc.so.7 => /lib/libc.so.7 (0x801212000) libgfortran.so.3 => /usr/local/lib/gcc5/libgfortran.so.3 (0x8015ca000) libm.so.5 => /lib/libm.so.5 (0x8018ec000) libquadmath.so.0 => /usr/local/lib/gcc5/libquadmath.so.0 (0x801b17000) libintl.so.8 => /usr/local/lib/libintl.so.8 (0x801d56000) libreadline.so.7 => /usr/local/lib/libreadline.so.7 (0x801f60000) libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x8021b0000) liblzma.so.5 => /usr/lib/liblzma.so.5 (0x802428000) libbz2.so.4 => /usr/lib/libbz2.so.4 (0x802651000) libz.so.6 => /lib/libz.so.6 (0x802865000) librt.so.1 => /usr/lib/librt.so.1 (0x802a7e000) libicuuc.so.58 => /usr/local/lib/libicuuc.so.58 (0x802c83000) libicui18n.so.58 => /usr/local/lib/libicui18n.so.58 (0x803200000) libgcc_s.so.1 => /usr/local/lib/gcc5/libgcc_s.so.1 (0x8036ac000) libncursesw.so.8 => /lib/libncursesw.so.8 (0x8038c2000) libthr.so.3 => /lib/libthr.so.3 (0x803b20000) libicudata.so.58 => /usr/local/lib/libicudata.so.58 (0x803d48000) libc++.so.1 => /usr/lib/libc++.so.1 (0x803f49000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x804210000) ``` `/usr/local/bin/R` is only a shell script.
(In reply to rs.os from comment #7) Add these lines to /etc/make.conf: WITH_DEBUG=Y DEBUG_FLAGS=-g FLAGS=-g CFLAGS=-g CPPFLAGS=-g STRIP= Rebuild: # portupgrade -f R Run under debugger and find the line where it crashes.
(In reply to rs.os from comment #0) This happend also on my recent HEAD amd64 boxes. I think, it has something to do with newer changes to libcurl (FreeBSD related)? At least, if I change the download method for packages within R, all went fine: update.packages(checkBuilt=TRUE, dependencies=TRUE, ask='graphics', method='wget') This also works with install.packages(..., method='wget')
The third call to CURLcode ret = curl_easy_perform(hnd); in in_do_curlGetHeaders() from src/modules/internet/libcurl.c triggers the problem _unless_ R is built with flang instead of gfortran. For FreeBSD 11.1 R users, there are two workarounds [1]. 1) Build the FreeBSD R package with the FLANG option instead of GFORTRAN. FLANG may be the default soon. 2) Add options(download.file.method="wget") to ~/.Rprofile with a newline after it. Ensure ftp/wget is installed, because it is not pulled in by math/R. [1] Both these workarounds prevent a predictable crash, but have only been lightly tested.
(In reply to Joseph Mingrone from comment #10) Then it might be crashing because of mixing of libgcc_s.so from gfortran and from the base.
I see the same result with USE_GCC=yes and using gfortran. A backtrace indicates the problem may be with lang/gcc5, so I'm copying gerald. Reading symbols from /usr/local/lib/R/bin/exec/R...done. [New LWP 100936] [New LWP 100805] Core was generated by `/usr/local/lib/R/bin/exec/R'. Program terminated with signal SIGSEGV, Segmentation fault. #0 x86_64_freebsd_fallback_frame_state (context=0x7fffdfffde20, context=0x7fffdfffde20, fs=0x7fffdfffdb70) at ./md-unwind-support.h:60 60 if (!( *(unsigned int *)(context->ra) == 0x247c8d48 [Current thread is 1 (LWP 100936)] (gdb) l 55 <pc + 14>: syscall 56 57 If we can't find this pattern, we're at the end of the stack. 58 */ 59 60 if (!( *(unsigned int *)(context->ra) == 0x247c8d48 61 && *(unsigned int *)(context->ra + 4) == 0x48006a10 62 && *(unsigned int *)(context->ra + 8) == 0x01a1c0c7 63 && *(unsigned int *)(context->ra + 12) == 0x050f0000 )) 64 return _URC_END_OF_STACK; (gdb) bt #0 x86_64_freebsd_fallback_frame_state (context=0x7fffdfffde20, context=0x7fffdfffde20, fs=0x7fffdfffdb70) at ./md-unwind-support.h:60 #1 uw_frame_state_for (context=context@entry=0x7fffdfffde20, fs=fs@entry=0x7fffdfffdb70) at /usr/home/jrm/scm/freebsd/freebsd-ports.svn/lang/gcc5/work/gcc-5.4.0/libgcc/unwind-dw2.c:1249 #2 0x00000008034bbfdb in _Unwind_ForcedUnwind_Phase2 (exc=exc@entry=0x8051d5830, context=context@entry=0x7fffdfffde20) at /usr/home/jrm/scm/freebsd/freebsd-ports.svn/lang/gcc5/work/gcc-5.4.0/libgcc/unwind.inc:155 #3 0x00000008034bc314 in _Unwind_ForcedUnwind (exc=0x8051d5830, stop=0x8039367b0 <thread_unwind_stop>, stop_argument=<optimized out>) at /usr/home/jrm/scm/freebsd/freebsd-ports.svn/lang/gcc5/work/gcc-5.4.0/libgcc/unwind.inc:207 #4 0x0000000803936613 in _Unwind_ForcedUnwind (ex=<optimized out>, stop_func=0x7fffdfffd948, stop_arg=0x8051d5600) at /usr/src/lib/libthr/thread/thr_exit.c:106 #5 thread_unwind () at /usr/src/lib/libthr/thread/thr_exit.c:172 #6 _pthread_exit_mask (status=<optimized out>, mask=<optimized out>) at /usr/src/lib/libthr/thread/thr_exit.c:257 #7 0x000000080393642b in _pthread_exit (status=0x8051d5600) at /usr/src/lib/libthr/thread/thr_exit.c:206 #8 0x0000000803928bcd in thread_start (curthread=0x8051d5600) at /usr/src/lib/libthr/thread/thr_create.c:289 #9 0x00007fffdfdfe000 in ?? () Backtrace stopped: Cannot access memory at address 0x7fffdfffe000
(In reply to Joseph Mingrone from comment #12) > I see the same result with USE_GCC=yes and using gfortran. A backtrace indicates the problem may be with lang/gcc5, so I'm copying gerald. C++ from gcc and clang can't be mixed. They use different versions of libgcc_s.so in the same process, and they are conflict with each other. This is a known problem, and one of the reasons to have flang as a fortran compiler. As far as I know, there is no simple solution that doesn't involve removing gcc.
It would be helpful to figure out what changed in 11.1 to determine if there is a solution. This wasn't a problem prior to 11.1, even when clang was used to compile the base system. We could make flang the default, but this only helps for amd64.
By the way, I don't see any c++ code in R. It's mostly mostly C and Fortran source under src/.
A commit references this bug: Author: jrm Date: Wed Aug 2 21:27:43 UTC 2017 New revision: 447178 URL: https://svnweb.freebsd.org/changeset/ports/447178 Log: math/R: Work around bug 221127. PR: 221127 Reported by: rs.os@t-online.de Changes: head/math/R/Makefile head/math/R/pkg-message
This bug motivated me to add the check for bad library mix: https://reviews.freebsd.org/D11812 It will probably fail on some of the involved packages when gfortran is used.
This looks like the same problem as https://lists.freebsd.org/pipermail/freebsd-current/2017-August/066855.html and https://lists.freebsd.org/pipermail/freebsd-current/2017-October/067254.html triggered by the curl port enabling THREADED_RESOLVER by default. It's not because of mixing the wrong libraries.
A commit references this bug: Author: tijl Date: Sat Nov 18 13:19:22 UTC 2017 New revision: 454429 URL: https://svnweb.freebsd.org/changeset/ports/454429 Log: Remove pkg-message about problems with gfortran. The problem has been addressed in r454161. PR: 221127 Changes: head/math/R/pkg-message