-
Notifications
You must be signed in to change notification settings - Fork 640
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Spurious documentation failures #7829
Comments
We split a Require Import in two to avoid reaching the timeout.
I could confirm that this issue occurs with coq-8.13.0 when it is built on NetBSD 9.1_STABLE. Furthermore, this issue is not spurious, and occurs consistently. |
@azarens-git are you building on a local machine or on a VM? Is this always this particular line which is timing out? |
Can you in fact share more details? (The line in question was already split to fix the problem in our CI. Therefore, it is likely that what you were hitting is actually a separate issue.) |
The relevant build log is attached. If desired, I could also supply the build configuration, but there's nothing extraordinary there besides a regular invocation of dune and the replacements python -> python3.9 and sphinx-build -> sphinx-build-3.9 The build was started in pkgsrc-current, by means of cd /usr/pkgsrc/lang/coq && make with version of coq pulled to 8.13.0. The failure occurs consistently; there has been no single build when it did not occur. The source tree is from coq's github repository, with tag V8.13.0.
|
I captured the chat between
|
The result of applying all input commands directly is as follows. ---8<---
The same version, but on Debian box:
The state of coqtop at that point is thus:
(about ≈33.8Gb virtual memory and ≈14.6Gb residential memory) on Debian box:
(about ≈492Mb virtual memory and ≈293Mb residential memory) ---8<--- I also noticed that during the build coqc tends to compile excessive amounts of RAM (around 100Gb). ---8<--- This is an interesting discrepancy. A question arises, whether it is natural and tolerable. If yes, then a reasonable solution would be to increase a time-out. However, if the opposite is true, then a different course of action would be desirable. |
No, that's not normal. Can you open a new issue (since this is really a different problem) with this example? It really looks out of the scope of a documentation issue to me. |
Agreed. Let me do a few more tests, though, to gather more details. |
I would still like to suggest that the timeout be increased, say to 120 seconds. Just to cover all bases (and machines where Coq is compiled into byte-code, etc.). |
This could lead to incredibly long compilation times for the doc without a clear diagnosis (whereas here you get a timeout failure and you understand and if you really need it, you can tweak the timeout locally). Note that compiling the doc is optional and a pre-compiled version being available on the web, it's not a big deal if it's not as robust as Coq compilation. |
Thank you for your input.
I suppose, a low default is not an unreasonable approach thereby. However, what about making the timeout easily settable. Could it be exposed in some sort of config file? Even an include file with just a constant would be acceptable, since it'll be easy for a package maintainer to patch it and then substitute values. The local issues, like e.g. memory usage, could and should be caught through local tests.
I would disagree. The local documentation is quite important, especially for a program like Coq, which focuses on correctness, and a number of other academic virtues. I also found the need to work with coq in a disconnected environment as a real and relevant one, both for others and for myself. Also, a system administrator would in general find much more work upon himself, if the release versions of a package fail intermittently. All in all, it is not unreasonable to say that making timeout configurable, while leaving the default as it is, would be a most pragmatic solution thereby. |
I have done some additional testing by building both packages with dune from opam on a NetBSD box and a Debian box. In both instances, I got a working coqtop that did not consume excessive amount of memory. In particular, it processed the input script previously referenced by me as follows: original script:
on NetBSD box:
on Debian box:
All in all, I'm glad that the issue got caught while the documentation was being compiled. |
Sounds good to me. Please open an issue for this specific request. |
Thank you. This is a good suggestion. Opened issue #13848. |
We observe an alarming rate of failures of the documentation build on GitLab these days:
In all these cases, the error is the same:
What is especially weird is that I'm under the impression that these failures started appearing after the merge of #7284 but what is weird is that this PR didn't touch the faulty line. It only added https://github.com/coq/coq/pull/7284/files#diff-d80ca9da497679f1161bfbf7e7ab7ce1R509 in some other place.
So I'm tempted by two solutions. Either separate these imports in several lines to make it less likely to reach timeout (which is already at 10s), or revert the change I just linked to, to see if it changes anything (in which case, it looks like a bug).
The text was updated successfully, but these errors were encountered: