lib-test test failure about liballocs

[stephenrkell]

Hmm. Interesting. That test is passing for me, but it is sensitive to things like memory placement.

The failure line (static.c:172) is testing for a NULL info pointer from dl_iterate_phdr, which should never happen. However, sometimes the optimizer merges abort() paths, so the line numbers are not reliable. Can you do

cd ~/Projects/liballocs && make -C src clean && make DEBUG=1

and generate another backtrace? That should rebuild with -O0.

For background: 'lib-test' exists for running unit tests that get baked into a special liballocs-test.so binary. The idea is that the test program dlopens that binary, and the unit tests are run in the constructor logic. This has always seemed ugly to me, but I don't know good ways of running unit tests that would work for liballocs.

[jryans]

Thanks for the context and tips!

Curiously, the test passes when rebuilding with DEBUG=1. Looking a bit further, it appears related to LTO:

If I change the following in src/Makefile, then the optimised build allows the test to pass:

-    FAST_EXTRA_CFLAGS := -O3 -DNDEBUG -flto -ffat-lto-objects
+    FAST_EXTRA_CFLAGS := -O3 -DNDEBUG

This is with gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0.

[stephenrkell]

This is fixed as of 0f044d6... following several changes to how this test works, it is now re-enabled.

It's arguably cheating a bit, because in the new way of things, this particular test isn't run against an optimised build of the main liballocs code... it uses a special build which is always -O0 -DDEBUG -DTEST. So I can't be sure whether there is any LTO issue. But enough has changed that that would morally be a different issue. LTO of liballocs will get more testing via libcrunch, which I will get running in CI soon-ish.