Upgrade to latest Ubuntu LTS

[jeroen]

Upgrade Ubuntu to get the latest sanitizers to stay in line with what CRAN is using.

[wch]

Have you tested to see if the build still works?

[jeroen]

No not yet (I was hoping for CI 😄 ).

[wch]

The automatic build only happen with the master branch. (It runs on a computer of mine because the builds take too long for CI services.)

When I tried to build, I get:

Step 5/18 : RUN apt-key adv --keyserver keyserver.ubuntu.com --recv-keys E298A3A825C0D65DFD57CBB651716619E084DAB9
 ---> Running in 47417a7a2ace
Warning: apt-key output should not be parsed (stdout is not a terminal)
Executing: /tmp/apt-key-gpghome.VXi19ngDES/gpg.1.sh --keyserver keyserver.ubuntu.com --recv-keys E298A3A825C0D65DFD57CBB651716619E084DAB9
gpg: key 51716619E084DAB9: public key "Michael Rutter <[email protected]>" imported
gpg: Total number processed: 1
gpg:               imported: 1
 ---> 91cca985a41d
Removing intermediate container 47417a7a2ace
Step 6/18 : RUN add-apt-repository "deb http://cran.r-project.org/bin/linux/ubuntu $(lsb_release -cs)-cran35/"
 ---> Running in c05da705cbb8
Hit:1 http://security.ubuntu.com/ubuntu focal-security InRelease
Hit:2 http://archive.ubuntu.com/ubuntu focal InRelease
Hit:3 http://archive.ubuntu.com/ubuntu focal-updates InRelease
Hit:4 http://archive.ubuntu.com/ubuntu focal-backports InRelease
Ign:5 http://cran.r-project.org/bin/linux/ubuntu focal-cran35/ InRelease
Err:6 http://cran.r-project.org/bin/linux/ubuntu focal-cran35/ Release
  404  Not Found [IP: 137.208.57.37 80]
Reading package lists...
E: The repository 'http://cran.r-project.org/bin/linux/ubuntu focal-cran35/ Release' does not have a Release file.
The command '/bin/sh -c add-apt-repository "deb http://cran.r-project.org/bin/linux/ubuntu $(lsb_release -cs)-cran35/"' returned a non-zero code: 100

[jeroen]

Ah ok, let me fix that...

[jeroen]

OK updated. Running build-all locally now, so far so good...

[jeroen]

Thanks!

[eddelbuettel]

Have you two tested the images? For RDcsan I get persistent errors such as C stack usage 7984768 is too close to the limit (even after reinstalling Rcpp and the package I am testing).

[wch]

I haven't tested RDcsan after the changes. If you're getting that message, it's likely this part needs to be tweaked:

r-debug/r-debug-3/Dockerfile

Lines 23 to 26 in 6d0dc7b

	# Modify the RDcsan script to increase stack size with `ulimit -Ss 65532`;
	# otherwise we get these messages during package compilation:
	# Error: compilation failed - C stack usage 8042720 is too close to the limit at NULL
	RUN sed -i 's/^#!\/bin\/bash/#!\/bin\/bash\nulimit -Ss 65532/' /usr/local/bin/RDcsan

[eddelbuettel]

Oh, nice. Do you have a suggested value? And "how much" then needs rebuilding? The container? Or just the package and its dependencies?

It's a bit weird. I was also running individual test files via RDcsanscript -- which would need a rebuild -- and when I run it via RDcsan -q -e '...' it passes (mosts) the tests but still yells loud and long to the console. Hm.

[wch]

To rebuild just the stage that provides RDcsan, you'll want to do:

docker build -t wch1/r-debug-3 r-debug-3

Then you can do docker run wch1/r-debug-3 to test it out.

To rebuild that stage and subsequent ones, the easiest way is to use buildall.sh. https://github.com/wch/r-debug/blob/6d0dc7be599da6bc9ba5a7e7265dcc14a36117e3/buildall.sh

RDcsan is a shell script where ulimit is set at the top, but RDscriptcsan is a binary, so I don't know how one would set the ulimit values for it, other than running ulimit from the command line. Maybe in .bashrc?

I don't really know what a good value is. You could try doubling it -- 128MB doesn't seem like a crazy amount of memory for this.

[eddelbuettel]

(I never rebuild 3.5gb images locally ;-) ) I remain a big fan of RHub Docker Hub for such builds...

But I'll keep that mind. Maybe if I'm bored. But you're building these nightly on a cron, no? Should we ... not just up the value?

Agreed re ulimit for the binary too...

(Edited: Replaced thinko RHub with Docker Hub)

[jeroen]

Interestingly, I have been debugging mysterious stack limit problems within V8 on Fedora 32. I suspect something may have changed in recent versions of the linux kernel that causes us to hit stack limits where we didn't before.

[wch]

@eddelbuettel I just doubled the stack size and and kicked off a rebuild.

@jeroen Are you using Docker? Because if so, it will use the same kernel as the host OS.

[eddelbuettel]

Will give that a spin later.

[ BTW Sent you and Joe email on another [CRAN-related] matter yesterday. Any chance you can follow-up? ]

[eddelbuettel]

@wch Looks like the doubled stack allotment did the trick! And better still I seem to have squashed the bug causing the ASAN error. So big Thank You! for the updated container!