Setting up man-db crashes system with Bad system calls

Ubuntu 18.04 x86_64. Ever since I upgraded from 17.10 to 18.04, whenever I install or run updates and the subsequent man-db update occurs, the system gets stuck for ten minutes or so spitting out errors and hitting the cpu hard.

Setting up man-db (2.8.3-2) ...
Updating database of manual pages ...
/usr/bin/mandb: zcat: Bad system call (core dumped)
/usr/bin/mandb: zcat < /usr/share/man/man1/wodim.1.gz: Bad system call (core dumped)
/usr/bin/mandb: /usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE -q: Bad system call (core dumped)
/usr/bin/mandb: zcat < /usr/share/man/man1/grub-editenv.1.gz: Bad system call (core dumped)
/usr/bin/mandb: zcat: Bad system call (core dumped)
/usr/bin/mandb: zcat < /usr/share/man/man1/grub-editenv.1.gz: Bad system call (core dumped)
/usr/bin/mandb: /usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE -q: Bad system call (core dumped)
/usr/bin/mandb: zcat < /usr/share/man/man1/grub-file.1.gz: Bad system call (core dumped)
.
.
.

Furthermore, manpages throw errors and are empty:

     Manual page man(1) line ?/? (END) (press h for help or q to quit)man: 
    zcat < /usr/share/man/man1/man.1.gz: Bad system call (core dumped)
    man: /usr/lib/man-db/manconv: Bad system call (core dumped)man: preconv: Segmentation fault (core dumped)
    man: tbl: Segmentation fault (core dumped)
    man: nroff: Bad system call (core dumped)
man: gzip: Bad system call (core dumped)

There's a bug report on Debian describing a similar issue, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890355, but I'm already running the version of man-db that supposedly fixed the problem (2.8.3). Tried reinstalling man-db to no effect. Did anybody experience anything similar, and how to fix?

Here is the link to the requested trace file:

manpage.trace

Solution 1:

I've had several replies to my request for strace output, for which many thanks. Most of them indicate use of the Astrill VPN software, which injects code into every process on the system using /etc/ld.so.preload, thus making effective process sandboxing quite a bit more difficult. I believe I've worked around this in git master.

One reply indicated use of the ESET File Security antivirus software, which does a similar thing. I've tried to work around problems with this in the past, but it seems to be a bit of a moving target. I've committed my best guess at a workaround to git master.

Assuming that I get some successful test reports about these changes, they'll be in man-db 2.8.4, and they're small and self-contained enough that I should be able to push them as stable updates to Ubuntu 18.04 as well.