FTBFS: core dump during doxygen run

[Andreas Hasenack]

https://launchpadlibrarian.net/676600060/buildlog_ubuntu-mantic-amd64.fenics-dolfinx_1%3A0.6.0-4_BUILDING.txt.gz

Generating XML output for file generation.cpp
Generating XML output for file generation.h
Generating XML output ferror: Failed to extract bounding box from generated diagram file /<<PKGBUILDDIR>>/cpp/doc/latex/d2/d97/classdolfinx_1_1io_1_1FidesWriter__inherit__graph.pdf
 (warning treated as error, aborting now)
Segmentation fault (core dumped)
make[1]: *** [debian/rules:168: override_dh_auto_install-indep] Error 139
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
make: *** [debian/rules:125: binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2

This might also be a bug in doxygen. It didn't happen in the other arches build (which were done days earlier than amd64), and is also not happening in debian.

From what I could see so far, in Ubuntu doxygen ends up calling dot, and dot errors with some file and exits. This exit status catches doxygen by surprise, and an atexit() handler crashes:

Thread 7 "doxygen" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe5dfa6c0 (LWP 30404)]
0x00007fffeaa3eb03 in __run_exit_handlers (status=1, listp=0x7fffeabf6840 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true,
    run_dtors=run_dtors@entry=true) at ./stdlib/exit.c:72
Download failed: Invalid argument. Continuing without source file ./stdlib/./stdlib/exit.c.
72 ./stdlib/exit.c: No such file or directory.
(gdb) bt
#0 0x00007fffeaa3eb03 in __run_exit_handlers (status=1, listp=0x7fffeabf6840 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true,
    run_dtors=run_dtors@entry=true) at ./stdlib/exit.c:72
#1 0x00007fffeaa3ed20 in __GI_exit (status=<optimized out>) at ./stdlib/exit.c:141
#2 0x0000555555d5778b in handle_warn_as_error () at /usr/src/doxygen-1.9.4-4/src/message.cpp:133
#3 0x0000555555d57b2f in err (fmt=fmt@entry=0x555556356e38 "Failed to extract bounding box from generated diagram file %s\n")
    at /usr/src/doxygen-1.9.4-4/src/message.cpp:237
#4 0x0000555555caebe4 in DotRunner::readBoundingBox (fileName=..., width=width@entry=0x7fffe5df9920, height=height@entry=0x7fffe5df9924,
    isEps=isEps@entry=false) at /usr/src/doxygen-1.9.4-4/src/dotrunner.cpp:135
#5 0x0000555555cafae9 in DotRunner::run (this=0x555556e57860) at /usr/src/doxygen-1.9.4-4/src/dotrunner.cpp:216
#6 0x0000555555cb13d5 in DotWorkerThread::run (this=0x555556bfee70) at /usr/src/doxygen-1.9.4-4/src/dotrunner.cpp:304
#7 0x00007fffeaee6383 in std::execute_native_thread_routine (__p=0x55555728c770) at ../../../../../src/libstdc++-v3/src/c++11/thread.cc:104
#8 0x00007fffeaa8f18a in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444
#9 0x00007fffeab1dbd0 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Investigation continues.

[Andreas Hasenack (ahasenack)]

Bug in doxygen: https://github.com/doxygen/doxygen/issues/9319

[Andreas Hasenack (ahasenack)]

The failure happens only on amd64 because that's where arch indep packages are built, and doxygen docs are just that:

d/rules:
build: with_docs=yes
build-arch: with_docs=no
build-indep: with_docs=yes

...
[ "no" = no ] || find build/html/examples/ -type f -iregex .*pdf -exec mat2 --inplace '{}' \;

The build on arm64, for example, only produces these debs:
doxygen-doxyparse_1.9.4-4build1~ppa1_arm64.deb (4.7 MiB)
doxygen-gui_1.9.4-4build1~ppa1_arm64.deb (580.7 KiB)
doxygen_1.9.4-4build1~ppa1_arm64.deb (4.8 MiB)

A working amd64 build, produces these:
doxygen-dbgsym_1.9.4-4_amd64.ddeb (63.1 MiB)
doxygen-doc_1.9.4-4_all.deb (2.0 MiB)
doxygen-doxyparse-dbgsym_1.9.4-4_amd64.ddeb (63.0 MiB)
doxygen-doxyparse_1.9.4-4_amd64.deb (4.7 MiB)
doxygen-gui-dbgsym_1.9.4-4_amd64.ddeb (2.7 MiB)
doxygen-gui_1.9.4-4_amd64.deb (271.6 KiB)
doxygen-latex_1.9.4-4_all.deb (4.2 KiB)
doxygen_1.9.4-4_amd64.deb (4.7 MiB)

[Andreas Hasenack (ahasenack)]

The cairo change to which doxygen had to adapt: https://gitlab.freedesktop.org/cairo/cairo/-/commit/bd514f6b08c1b31a75948fd99c147319e5aa649f

[Andreas Hasenack (ahasenack)]

I went over the upstream git repo and cherry-picked commits to fix this. There are many :/

$ grep ^commit debian/patches/doc-build-with-newer-cairo-*.patch
debian/patches/doc-build-with-newer-cairo-1.patch:commit c22ae5ed4ca8d7e5568be7d5a930ee388117703e
debian/patches/doc-build-with-newer-cairo-2.patch:commit 9df76e22464a0b6302b7c1cda980a35b39185bc4
debian/patches/doc-build-with-newer-cairo-3.patch:commit 293d3beaf03c8798899332b7a948b32c4a3da3e9
debian/patches/doc-build-with-newer-cairo-4.patch:commit 966d69c603b5a6ae22e3132b6ecc6a39b86e52ab
debian/patches/doc-build-with-newer-cairo-5.patch:commit 7b2a6027775b0158304635a98de0f9b5672f163a
debian/patches/doc-build-with-newer-cairo-6.patch:commit 8129939c312e4b5060042fdb93bd071b7b133381
debian/patches/doc-build-with-newer-cairo-7.patch:commit e002e293d9dc956a0634b3a4bcc8d93e655582d5

It's probably less risky to update to 1.9.7.

I'll post this info in the debian bug too, see what the maintainer prefers, before taking further action.

WIP branch: https://code.launchpad.net/~ahasenack/ubuntu/+source/doxygen/+git/doxygen/+ref/mantic-doxygen-cairo-compat

PPA: https://launchpad.net/~ahasenack/+archive/ubuntu/doxygen-et-al

[Dan Bungert (dbungert)]

There is a workaround for fenics-dolfinx of setting `WARN_AS_ERROR = NO` in cpp/doc/Doxyfile, but given what's failing (doxygen looking for a MediaBox that isn't there), the results may not actually be correct.

[Andreas Hasenack (ahasenack)]

Debian said they would prefer to update doxygen to 1.9.7, and would take care of it. I would rather not go ahead of debian with a new upstream version and give them a few days to update.

[Andreas Hasenack (ahasenack)]

Still no move on the debian side. I have a branch and ppa with the patches from comment #4, but it's a big set of patches, it's even pulling in a gzip decompressor (TinyDeflate - commit 966d69c603b5a6ae22e3132b6ecc6a39b86e52ab).

Another alternative is to export CAIRO_DEBUG_PDF=1 before running doxygen. That will produce PDFs with the MediaBox as before, but I don't know what else will change in the generated PDF, and it's definitely a workaround just for fenics-dolfinx, not any other package using doxygen.

[Andreas Hasenack (ahasenack)]

I grepped the cairo source, and the only usage of CAIRO_DEBUG_PDF is this:

    if (getenv ("CAIRO_DEBUG_PDF") != NULL)
        surface->compress_streams = FALSE;

Which is exactly what we want...