ARROW-6214: [R] Add R sanitizer docker image

[fsaintjacques]

The PR creates a docker image to replicate R sanitizer errors. One can iterate with arrow local sources without installing CRAN arrow package.

A real undefined behaviour was fixed in array_to_vector.cpp. The other errors were false positives (to best of my knowledge).

[fsaintjacques]

@jeroen, @romainfrancois

[nealrichardson]

I think this fixes one issue, but there may be more.

I've been exploring using the pyarrow manylinux wheel (or something similar) as a source of C++ binaries for the R package. After some trial-and-error, I got the package to build successfully, but then it core dumped when running the test suite, very similar to the situation we observed on the CRAN macOS server that led to this JIRA.

I pulled this change to array_to_vector.cpp onto the arrow fork/branch I was using and ran the build again, and it core-dumped again... but differently! This makes me suspect that there's another problem left to sanitize.

I'll investigate more on my side and see if I can identify where this is failing. Could be unrelated, of course.

[fsaintjacques]

This feels like an out of memory issue (both happen in allocation path + non determinism).

[fsaintjacques]

If you have a local mac, you can try to reproduce with ulimit, e.g.

(ulimit -m $((1024 * 1024 * 256)); R < testthat.R)

You might have to find the right ulimit flag (-m, -v)

[nealrichardson]

The failures were on xenial ubuntu, not macOS. I was able to use the wheel as a binary source on macOS just fine.

I ran the tests with more verbosity and incrementally skipped the ones that triggered a core dump. It turned out that the specific exception was somewhat random even when the same test was failing, either bad_alloc or length_error, so the fix I pulled in from this branch might not have made the difference I thought before.

I eventually got the build to pass once I skipped enough tests: nealrichardson/arrow@0.14.1.1-rpkg...nealrichardson:wheel-debug

All of the failures were tests that were trying to do something (mostly, and perhaps only, cast()) that was expected to fail and then assert the error message. For some reason this passes on most platforms and C++ build setups, but is failing on Travis on xenial using the pyarrow manylinux2010 wheel as the source for C++ binaries.

I don't know that I can debug this further, but maybe this information is useful to you/others who are more fluent in C++.

[nealrichardson]

After some spelunking, we've come to suspect a mismatch between the (old) compiler used in manylinux2010 and the one used here in xenial. François added some gdb debugging, and we saw that the problem was coming from the exception handler inside Rcpp::stop: https://travis-ci.org/nealrichardson/sandbox/builds/586674948#L1546. https://stackoverflow.com/questions/56494095/rcppstop-crashes-r-under-g suggests that compiler version mismatch could be to blame.

Anyway, this turns out to be irrelevant for the current pull request.

[nealrichardson]

@ursabot crossbow submit docker-r

[ursabot]

AMD64 Conda Crossbow Submit (#63464) builder has been succeeded.

Revision: 3af4ccc

Submitted crossbow builds: ursa-labs/crossbow @ ursabot-203

Task	Status
docker-r

[fsaintjacques]

@ursabot crossbow submit docker-r-sanitizer

[ursabot]

AMD64 Conda Crossbow Submit (#63615) builder has been succeeded.

Revision: 55d28ea

Submitted crossbow builds: ursa-labs/crossbow @ ursabot-206

Task	Status
docker-r-sanitizer

[fsaintjacques]

This is now passing travis' lint: https://travis-ci.org/fsaintjacques/arrow/builds/587033835?utm_medium=notification&utm_source=email