Don't crash or generate invalid XML for empty TOC

[mosra]

The new XML TOC implementation from #736 is not handling TOC on pages without @sections correctly, accessing a null pointer. This adds a corresponding test and a fix. Interestingly enough, the docbook and XHTML generators are already handling this case properly.

I also added a test for TOC levels that could lead to bugs like those fixed in #6696 and #6697. The XML output is not affected by these but having an explicit test for it certainly won't hurt.

What concerns me and what I would like to have fixed in additon to merging this PR is that on a larger project (Magnum), doxygen didn't crash on this but rather exited with a success return code and generated empty XML for given page and truncated index.xml. That's similar to the issue with a fix for #6277 that I reported a year ago (also accessing a null pointer, fixed in 1a1fdbe). My question/request is:

• Why doxygen executed by runtests.py crashes in this case and why doxygen executed on a larger project fails silently, making the error much more confusing and harder to spot? Is it because threads are involved?
• Is it possible to propagate the aborted operation (from the thread?) all the way to the return code of the doxygen executable, so the crash is never silent?

[albert-github]

@mosra you wrote:

Interestingly enough, the docbook and XHTML generators are already handling this case properly.

This is quite recently fixed when doing some tests regarding XHTML. The underlying problem is that the writing of the XML output follows a quite different way than (X)HTML, LaTeX, RTF, Docbook and ... do (Docbook since the 1.8.15 release). In this case the XML part is easily overlooked.
It would, in my opinion, be beneficial when XML also follows the same strategy as (X)HTML etc.

Doxygen hardly uses threads of its own (only for dot as far as I know) and it is bad that it does crash in one case and not in an other. I think that the not crashing is "luck" in the sense that a not fatal part of the memory is hit and used correctly and in the other case (luckily) the program crashes, maybe some stricter memory access checking (compiler setting) would help but probably at the costs of a, much, longer run time (I always compare it with the Fortran possibility to use do boundary checking on arrays where is is possible to access array elements outside and array without problems unless you compile with boundary checking. In the later case at runtime the out of bound check will seen and stop the program).

[mosra]

The underlying problem is that the writing of the XML output follows a quite different way than (X)HTML, LaTeX, RTF, Docbook and ... do

Looking at how much of the logic is repeated for every output format, I'm thinking that the best way would be to have XML as an intermediate format with all others created from it to avoid repeating the same code. That could be for example via XSLT for the XML-based outputs (HTML and Docbook) and via some templating logic (similar as Python's Jinja) for the others. But that's for a separate discussion...

Doxygen hardly uses threads of its own (only for dot as far as I know) [...] I think that the not crashing is "luck" in the sense that a not fatal part of the memory is hit and used correctly

It results in a file being written partially, so there has to be some sort of crash. It's accessing memory at address 0, no amount of "luck" should make it survive. Threads is one explanation, another could be that SIGABRT / SIGSEGV signals are intercepted (for whatever reason) and instead of crashing they get ignored. I know very little about the internals so I don't even know where to look -- and it happens on a project that takes several seconds to process. It's also maybe happening only on Linux, I have no idea how the behavior of this is on Windows. In case you'd want to try to reproduce:

git clone git://github.com/mosra/magnum
git clone git://github.com/mosra/magnum-extras # this one contains the empty page TOC
cd magnum
mkdir build
doxygen Doxyfile-mcss # ignore warnings, these are due to missing tagfiles from other projects

# if it doesn't crash, build/doc/index.xml should be truncated and build/doc/ui.xml empty