Bypass library finalisation to fix libgomp crash

[lionel-]

(Hopefully) fixes these flakes:

     SIGABRT [   0.980s] ( 667/1297) ark::dap_notebook test_notebook_debug_info
  stdout ───

    running 1 test
    test test_notebook_debug_info ... ok

    test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 18 filtered out; finished in 0.21s

  stderr ───
    dap_notebook-d63c677b2730ef53: ../../../src/libgomp/oacc-init.c:84: goacc_register: Assertion `!dispatchers[disp->type]' failed.

    (test aborted with signal 6: SIGABRT)

libgomp is a library loaded via BLAS on our Ubuntu runners. The stderr output indicates that the library is getting initialised a second time, triggering this assertion abort.

We still don't know why libgomp is getting initialised a second time, but we know that it happens after the test passed (e.g. ok result in output). We also know from LD_DEBUG output that it happens during linked library teardown when the process exits:

calling fini: libR.so [0]
calling fini: libgomp.so.1 [0]
find library=libR.so [0]; searching
calling init: libgomp.so.1    ← second init triggers assertion failure

According to glibc'd deepwiki, library finalisation happens via the atexit hook, registered very early by the dynamic linker at process startup. The workaround implemented in this PR is to register an atexit hook in the test harness on Linux to call _exit(), which is documented to exit immediately without any further cleanup (https://man7.org/linux/man-pages/man2/_exit.2.html):

The function _exit() is like exit(3), but does not call any functions registered with atexit(3) or on_exit(3).

Furthermore, from exit() (https://man7.org/linux/man-pages/man3/exit.3.html):

If one of these functions [from atexit] does not return (e.g., it calls _exit(2), or kills itself with a signal), then none of the remaining functions is called, and further exit processing (in particular, flushing of stdio(3) streams) is abandoned.

So exiting with code 0 from an atexit hook should circumvent all this library finalisation procedure.

[lionel-]

40 successful runs of Linux CI 🤞

[DavisVaughan]

i think a note about this being for data table when we need to compile from source would be useful, otherwise im left going 'wtf is this for'

[lionel-]

it's for any package we need to compile, not just data.table. It's basic Makevars configuration for that runner

[lionel-]

      # This configures Makevars to look for brew headers and libraries. Useful
      # to compile packages used in tests when they have just been released to
      # CRAN and there is no binary we can download yet. We've needed this for
      # data.table.

[DavisVaughan]

I rarely if ever need to fiddle with makevars on ci anymore, even for compiled packages, so some kind of justification always feels necessary when i need to have something like this

[DavisVaughan]

i think we should do this instead

https://github.com/Rdatatable/data.table/blob/cd3ef291a67b28daeaa2669d8e98aaf5dbfb0ac4/.github/workflows/R-CMD-check.yaml#L49-L53

its tailor made for this use case

stan-dev/cmdstanr#1072

R no longer bundles libintl, and the current setup-r-dependencies action r-lib/actions#998, so it was recommended we use separate action for this

and libintl was the problem

[lionel-]

Not sure about tailor made for this use case. It's presented as one of the potential solutions, along with installing the dep yourself.

In this case we already have the system lib, somehow, so downloading all sys reqs again (326mb) to extract a copy in /opt/R seems a bit heavy handed compared to pointing R to the brew files. Perhaps it's more future proof than whatever we did to the CI setup causing the sysreq to be already installed by brew. I wouldn't worry about this for now though.