It turned out slightly more complicated, the fallback to AST is was
already in place, but memory available to malloc got exhausted via heap
expansion. Messages starting "Error: compilation failed" mean there was
an error while compiling, including out of memory, and that the AST will
be used - so these are worth looking at but not fatal. The error message
"cannot allocate buffer" was the real problem.
We have addressed that with Luke in R-devel and R-patched (more general
fix might come later to R-devel only). Now there is a GC on the fallback
path which should release some memory from R heap to be usable by malloc
again. Also, the compiler needs a bit less memory when analyzing similar
code patterns as those causing trouble in fBasics (solves the fBasics
problems with "ulimit -v 1000000")
Best
Tomas
On 06/05/2018 08:59 PM, Dirk Eddelbuettel wrote:
On 4 June 2018 at 20:06, Tomas Kalibera wrote:
| thanks for the report. Access to the test system is not necessary, the
| memory requirements of the byte-code compiler are usually
| platform-independent and specifically with this package I can reproduce
| they are very high. We'll have a look what we can do, certainly there
| should at least be a way to recover and use the uncompiled version when
| memory allocation fails, this is already done by the JIT but not when
| compiling during installation. Before R or the package is patched, the
| only workaround for memory constrained systems is probably to disable
| byte-compilation of this package, as I read you are doing already.
Yes. And as a shortcut, we just turned it off unconditionally, ie on all
build architectures. Worked fine as per
https://buildd.debian.org/status/package.php?p=fbasics
it has been built everywhere where we have R 3.5.0 (some 20 or so platforms).
The fix you suggest sounds ideal: if possible recover, and maybe WARN.
Dirk
