Generated filenames depend on undefined behaviour - doxygen output not reproducible #8752
Labels
Comments
ellert
changed the title
|
@ellert I haven't been able to reproduce this myself. Can you attach a self-contained example that shows the problem? Regarding Line 11521 in e84b043 Line 11795 in e84b043 A simple example with some dummy files in dummy directories, shows that the order of searching is not defined: but then parsing the files and creating the directories uses the sorted list, so should be reproducable I've added the example I used to try to reproduce the issue: |
|
Hi! I added a debug statement to doxygen, at the place where the directories are assigned numbers (m_dirCount): These two files show the result of these outputs of two different architectures. The order between the two is similar, except that in one the directory roofit/roofitcore/src has number 501, and in the other 509 (with the intermediate directories shifted one position). The m_dirCount of the directories then become part of the name of some generated files, which makes the set of files different. Let me know if I can provide more information. |
|
The log files are a bit hard to read as they contain a lot of extra information, but after searching for I have seen that recently some changes were made regarding some order of processing in the master version (at first glance I thought for an unrelated topic though it might have an influence here as well, it is for the issue #8767 commit: 8ee3097).
|
|
@ellert I haven't been able to really reproduce the problem, but I did make some changes to make the |
|
Unfortunately a regression has been found: All based on the moodle package processed by Fossies. |
doxygen
added a commit
that referenced
this issue
Sep 12, 2021
|
@albert-github Ah, I see |
|
Unfortunately still: |
|
@albert-github hmm, makes little sense to me. Did you do a clean build (or does it help if you do)? And if not, what are the values of d1->shortName().data() and d2->shortName().data() at the moment of the crash? |
|
@albert-github I think I found the problem. The sorting logic was wrong. Please try again with the latest commit. |
I can confirm that this solves the problem for me. (I did get a segfault with just the first commit though.) |
albert-github
added
fixed but not released
|
it seems the problem is not yet completely solved. The problem still appears when building the libspf2 package for Fedora. Here is an example: https://koji.fedoraproject.org/koji/taskinfo?taskID=77732452 The build is rejected because: |
|
|
i have used the lastest doxygen git version (57d3172) I also attached the source+configuration file in a tar file |
You mentioned the doxygen 1.9.3 (57d3172) version, but you said you compared but with what is it compared? Forgot to mention in the previous comment:
|
|
This issue was previously marked 'fixed but not released', |
doxygen
removed
the
fixed but not released
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When building documentation with doxygen 1.9.2 the filenames for the directory dependencies generated here:
doxygen/src/dotdirdeps.cpp
Line 165 in 8bbce64
are not reproducible. The dirCount() value depends on the order in which the files are scanned, which depends on the std::filesystem::directory_iterator. This order is not deterministic.
https://en.cppreference.com/w/cpp/filesystem/directory_iterator
says: "directory_iterator is a LegacyInputIterator that iterates over the directory_entry elements of a directory (but does not visit the subdirectories). The iteration order is unspecified, except that each directory entry is visited only once. The special pathnames dot and dot-dot are skipped."
Since the dirCount() values are not guaranteed to be constant between runs, they can not be used in the generated documentation or in the filenames used to save it, or the result is not-reproducible.
This causes problems when building packages for Fedora, since packages are built for multiple architectures, and the build system (koji) rejects builds where the set of filenames in a non-architecture dependent (noarch) package is different when built on different architectures.
Here is an example: https://koji.fedoraproject.org/koji/taskinfo?taskID=74850762
The build is rejected because:
The text was updated successfully, but these errors were encountered: