-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
compiletest fails when rustc prints too much JSON #115675
Comments
Ouch, yeah. Is that max-size logic really needed? And if yes, can we (a) increase the size to something much bigger, and (b) not print anything after the skipped parts so that one is more likely to notice? |
The max-size logic is there to avoid OOM errors, which end up not printing anything at all. The current size limit was chosen to serve as an indicator of a test that is generating too much output (for example, it discovered #94327, which can be a problem for editors needing to ingest too much (useless) data). I imagine it can be raised a little bit, but I would caution against raising it too high. |
Make compiletest output truncation less disruptive When the test output becomes too large, compiletest stops recording all of it. However: - this can lead to invalid JSON, which then causes compiletest itself to throw further errors - the note that output was truncated is in the middle of the output, with >100kb of text on each side; that makes it almost impossible to actually see that note in the terminal So assuming that we do need to keep the output truncation, I propose that we only ever do a cut at the end, so that it is very clear by looking at the end of the log that truncation happened. I added a message at the beginning of the output as well. Also I added some logic to make it less likely that we'll cut things off in the middle of a JSON record. (I tested that successfully by reducing the output limit to something very low and running a few ui tests.) Furthermore I increased the max buffer size to 512KB; that's really not a lot of memory compared to how much RAM it takes to build rustc (it's ~25% more than the previous maximum HEAD+TAIL length). And finally, the information that things got truncated is now propagated to the higher levels, so that we can fail the test instead of comparing the truncated output with the reference. Fixes rust-lang/rust#115675 Fixes rust-lang/rust#96229 Fixes rust-lang/rust#94322 Fixes rust-lang/rust#92211
Sometimes a rustc ICE (or rustc invocation in general) can produce so much output that compiletest's logic to skip part of the output kicks in, and then that logic destroys the JSON format, and then compiletest fails. Then things become essentially impossible to debug, since the output you get looks like this (reduces to fit into a github issue):
It actually looks a lot better on github than it does on the terminal, since on github it doesn't line-wrap. When this gets line-wrapped, you cannot even tell that there is a "SKIPPED" message in the middle, it's just a huge pile of raw JSON (basically the entire terminal backlog) that contains the backtrace in an unreadbale way.
Looking at the skipping logic, there are some indications that it tries to be JSON-aware, but clearly that's not working.
The text was updated successfully, but these errors were encountered: