Description of problem:
R segfaults during 'make check'
running code in 'lm-tests.R' ... OK
comparing 'lm-tests.Rout' to './lm-tests.Rout.save' ... OK
/bin/sh: line 1: 4258 Segmentation fault (core dumped) LANGUAGE=en LC_ALL=C SRCDIR=. R_DEFAULT_PACKAGES= ../bin/R --vanilla < ok-errors.R > ok-errors.Rout.fail 2>&1
running code in 'ok-errors.R' ...Makefile.common:89: recipe for target 'ok-errors.Rout' failed
make: *** [ok-errors.Rout] Error 1
make: Leaving directory '/builddir/build/BUILD/R-3.1.1/tests'
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. ppc-koji build --scratch f21 R-3.1.1-3.fc21.src.rpm
I don't have any PPC machines, so this bug is probably going to sit here doing nothing. That said, you might try:
* Running the core through gdb and seeing if anything obvious happens there.
* Filing a bug with the R upstream (including the core and/or backtrace)
Created attachment 934322 [details]
I did a mock build on a ppc64 guest and failed the same way as above.
I found the following "ok-errors.Rout.fail" file in the tests/ subdir.
as per its comment seems the tests voluntarily tried the limits.
next attachment with gdb
Created attachment 934326 [details]
the attached R_gdb_core_backtrace.log show that core is a concequence of the infinit loop in eval.c that is detected but seems not handled properly.
#9101 0x00003fff797cf47c in do_begin (call=0x1003732faa8, op=0x100362a4120, args=0x1003732f840, rho=0x1003730c7a8) at eval.c:1633
#9102 0x00003fff797cbfa4 in Rf_eval (e=0x1003732faa8, rho=0x1003730c7a8) at eval.c:629
#9103 0x00003fff797cdadc in Rf_applyClosure (call=<optimized out>, op=<optimized out>, arglist=0x10036298888, rho=<optimized out>, suppliedenv=0x100362cb548) at eval.c:1044
#9104 0x00003fff797cbd44 in Rf_eval (e=0x1003732f878, rho=0x1003732f450) at eval.c:676
#9105 0x00003fff797cf47c in do_begin (call=0x1003732faa8, op=0x100362a4120, args=0x1003732f840, rho=0x1003732f450) at eval.c:1633
#9106 0x00003fff797cbfa4 in Rf_eval (e=0x1003732faa8, rho=0x1003732f450) at eval.c:629
#9107 0x00003fff797cdadc in Rf_applyClosure (call=<optimized out>, op=<optimized out>, arglist=0x10036298888, rho=<optimized out>, suppliedenv=0x100362cb548) at eval.c:1044
#9108 0x00003fff797cbd44 in Rf_eval (e=0x1003732f4f8, rho=0x100362cb510) at eval.c:676
#9109 0x00003fff798034d4 in Rf_ReplIteration (rho=0x100362cb510, savestack=<optimized out>, browselevel=<optimized out>, state=0x3fffd16afb50) at main.c:260
tracked upstream by https://bugs.r-project.org/bugzilla/show_bug.cgi?id=15963
(In reply to Tom "spot" Callaway from comment #1)
> I don't have any PPC machines, so this bug is probably going to sit here
> doing nothing. That said, you might try:
Tom, we do have ppc64 systems for that. Please ask on #fedora-ppc or send me your public ssh key.
The issue is related to the stack being too small when running the ok-errors.R test case. This test will cause an infinite recursion loop, which should be interrupted by R. On x86_64, this works as expected. On ppc64, the stack size needs to be doubled to 16384 (ulimit -s 16384) to be able to run successfully, otherwise the segfault will happen.
I'm currently testing ppc64 builds with modifying the ulimit before running 'make check' in the .spec file.
Created attachment 938242 [details]
Patch to R.spec file with a fix
R-3.1.1-6.fc21 has been submitted as an update for Fedora 21.
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing R-3.1.1-6.fc21'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
R-3.1.1-6.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.