Comment 18 for bug 1717574

Local repro possible with:
$ apt build-dep clamav
$ apt source clamav
$ cd clamav-0.99.2+dfsg
$ debuild -uc -us

Works on Zesty but fails on Artful.

They fail on the same bytecode test/sample file that is part of the unit test:
17076af1234ae2fa2e108ee234e9c578 /root/clamav-0.99.2+dfsg/unit_tests/input/bytecode.cvd

Rerun just the test with:
$ ./unit_tests/check_clamav --lt-debug

It will fail with the same signal 6 errors as "the real case", to debug you can use the libtool wrapper mode and need to get to the right fork (it does a lot):
$ libtool --mode=execute gdb ./unit_tests/check_clamav
+ some tricks to get to the right fork

It might be easier than fork hopping to drop all but:
srunner_add_suite(sr, test_bytecode_suite());
And then run "make check" to rebuild.

On that you can switch llvm's for debugging as you want (no dependencies of the packages, just rebuild clamav and retest)

Forcing in the zesty llvm via:
$ apt install llvm-3.9=1:3.9.1-5ubuntu1 llvm-3.9-runtime=1:3.9.1-5ubuntu1 llvm-3.9-dev=1:3.9.1-5ubuntu1 libllvm3.9=1:3.9.1-5ubuntu1
That makes it work (after doing a debuild again).

So I wondered what if I do "build" it against the old 1:3.9.1-5ubuntu1, but then upgrade to 1:3.9.1-16ubuntu1 - but that fails as well (actually that matches our case as clamav was build for artful before the upgrades)

Summarize:
- a regression due to the llvm updates
- executing the same bytecode from the unittest
- makes clamav fail in artful and being an FTBFS
- rebuilds against new llvm do not un-break it
- it could be an ABI change between the clamav delivered bytecode.cvd vs our change

Maybe some of the symbol mangling you mentioned to downsize it again was destructive?
You can now at least hop through llvm versions/builds and test it easily.
I hope this gives you enough repro steps to look into it with the llvm-expert POV.