[Rd] Very hard to reproduce bug (?) in R-devel

[Winston Chang]

Hi Dirk, I sent another message just before yours, so you may not have seen
it:

===========

I just tried recompiling R with no -O flag, and I still get the same error.
Here are the CFLAGS (the RD program runs R-devel instead of R 3.3.3):

# RD CMD config CFLAGS
-g -fdebug-prefix-map=/build/r-base-3.3.3=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g

===========

Additionally, I tried again with the rocker/r-devel-san image, and got the
same error. There was no other output from the sanitizers. In this
container:

# RD CMD config CFLAGS
-pipe -Wall -pedantic -O2 -mtune=native -fsanitize=address

The output looks like this (it should be in order --1--, --2--, --3--,
repeat):
20170405-213410.095858-18 20170405-213420.085451-17
20170405-213550.084947-16 --1--
20170405-213410.095858-18 20170405-213420.085451-17
20170405-213550.084947-16 --1--
20170405-213410.095858-18 20170405-213420.085451-17
20170405-213550.084947-16 --2--
20170405-213410.095858-18 --3--
20170405-213420.085451-17 20170405-213550.084947-16 --1--
20170405-213420.085451-17 20170405-213550.084947-16 --2--
20170405-213420.085451-17 --3--
20170405-213550.084947-16 --1--
20170405-213550.084947-16 --2--
20170405-213550.084947-16 --3--
 --2--
20170405-213410.095858-18 --3--
1. Error: pool scheduler: schedules things in the right order
(@test-scheduling.R#13)
could not find function "task"
1: naiveScheduler$protect({
       scheduleTask(1e+05, function() {
           results <<- c(results, 3L)
       })
       scheduleTask(10000, function() {
           results <<- c(results, 2L)
       })
       scheduleTask(10, function() {
           results <<- c(results, 1L)
       })
   }) at testthat/test-scheduling.R:13
2: private$refCount$release() at testthat/test-scheduling.R:13
3: private$callback()

-Winston


On Wed, Apr 5, 2017 at 4:32 PM, Dirk Eddelbuettel <edd at debian.org> wrote:

>
> On 5 April 2017 at 15:46, Winston Chang wrote:
> | On Wed, Apr 5, 2017 at 2:24 PM, Robert McGehee <
> rmcgehee at walleyetrading.net>
> | wrote:
> |
> | > Winston,
> | > I had a similar experience to you tracking down an insanely difficult
> bug
> | > in my R code that "disappeared" whenever slight changes were made to
> the
> | > script (e.g. like adding cat() statements). In my case, it coincided
> with
> | > my over-eager compilation of R and its library stack, as I was also
> | > experimenting with a cutting edge version of the gcc compiler as well
> as
> | > what I thought were innocuous performance enhancing CFLAGS like
> -O3/-Ofast
> | > -march=native. After downgrading gcc and recompiling everything (R and
> | > BLAS) without the extra flags, the problem went away. Not saying this
> is
> | > your problem, just sharing my similar experience.
> | >
> | >
> | Thanks Robert. I'm glad that I'm not the only one who's encountered an
> | issue like this. "Insanely difficult" is an apt description. :)
> |
> | I've been using the rocker/r-devel for testing. It compiles R with the
> | following CFLAGS:
> |   -g -O2 -fdebug-prefix-map=/build/r-base-3.3.3=.
> -fstack-protector-strong
> | -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g
> | It looks like it gets those settings from running R CMD config CFLAGS
> with
> | the already-installed version of R (3.3.3) which comes from a .deb
> package.
> |   https://github.com/rocker-org/rocker/blob/master/r-devel/
> Dockerfile#L76
>
> That's a Debian default a Policy-conforming offical package must use.
>
> For Docker you get these from the (prebuild) .deb package, you get it when
> you do r-devel by hand as they come back in via R CMD CONFIG:
>
>   https://github.com/rocker-org/rocker/blob/master/r-devel/
> Dockerfile#L76-L77
>
> You could undo those two lines / set CFLAGS and CXXFLAGS by hand.
>
> | I've also compiled R (again, in Docker) and tested with that, and gotten
> | the same results. It basically uses just `./configure
> | --without-recommended-packages`
> | and then `make`.
>
> Then these options should not come in.  But are you saying that the
> Heisenbug
> behaviour happens irrespective of the compilation flags?
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
>

	[[alternative HTML version deleted]]