Uh oh!
There was an error while loading. Please reload this page.
Filter backtrace - #48702
Conversation
rust-highfive
commented
Mar 3, 2018
r? @BurntSushi (rust_highfive has picked a reviewer for you, use r? to override) |
bjorn3
commented
Mar 16, 2018
ping @BurntSushi |
BurntSushi
commented
Mar 16, 2018
alexcrichton
left a comment
There was a problem hiding this comment.
Thanks for the PR and sorry for the delay! Dealing with filtering backtraces is a pretty tricky issue though so I'd want to be sure that we're being careful here. This all started in #38165 and some refinements were proposed in #40264 but during that discussion (and while the original PR was baking on nightly) it was found out that we were too aggressive about pruning backtraces, consequently leading to #41364 which removed almost all filtering.
There's a lot of comments on #40264 but I think the general consensus is that we're not shooting for 100% clean backtraces here but rather "mostly clean" backtraces by default. In that sense we're mostly looking to simply prune the top frames related to panic runtime gunk and the bottom frames that are related to thread start and whatnot (only showing user-written Rust code in the middle in theory).
To that end I think the logic here is a bit too aggressive, filtering out frames in the middle by accident possibly. Additionally searching for strings like panic or sys is pretty general, so I think we'd want to refine those as well.
Can you also gist some before/after of what the backtraces look like?
| /src/libstd_unicode/UnicodeData.txt | ||
| /stage[0-9]+/ | ||
| /target | ||
| target/ |
There was a problem hiding this comment.
Ah unfortunately this has the unintended side effect of ignoring src/librustc_back/target, so perhaps these changes could be left out for now?
| for (index, frame, is_on_filter_edge) in filtered_frames { | ||
| // Don't use ANSI escape codes on windows, because most terminals on it don't support them | ||
| if is_on_filter_edge && cfg!(not(windows)) { | ||
| write!(w, "\x1B[2m")?; |
There was a problem hiding this comment.
Dealing with ansi codes can be sort of a minefield unfortunately. This isn't handling terminals on Unix, for example, that don't support ansi codes. It also doesn't handle cases on Windows where ansi codes are supported (like MSYS and newer Windows terminals I think).
I'm not entirely certain what this ansi code is doing, but could it be left out for now?
There was a problem hiding this comment.
This ansi code makes the line darker, as it is less important.
There was a problem hiding this comment.
Ok, in that case can this be omitted for now? I'm not sure that libstd is really prepared to accurately place ANSI codes everywhere
| /// If the bool is true the frame is on the edge between showing and not showing. | ||
| fn filter_frames<'a>(frames: &'a [Frame], | ||
| context: &BacktraceContext, | ||
| format: PrintFormat) -> Vec<(usize, &'a Frame, bool)> |
There was a problem hiding this comment.
Backtraces are currently generated in some sensitive contexts that often work best if we avoid allocation as much as possible, so could a callback or a different scheme be used instead of a vector?
There was a problem hiding this comment.
Yes, but it is harder, due to having to know if the previous or next frame have to be filtered out.
There was a problem hiding this comment.
Ok, I think this'll be a requirement for landing though
bjorn3
commented
Mar 17, 2018
I want to extend this PR, so that you could set custom filters (eg. don't show the internal details of the rustc query system).
I can make it search a prefix instead. |
bjorn3
commented
Mar 17, 2018
alexcrichton
commented
Mar 19, 2018
I think that's something that we probably don't want in std itself, but perhaps an external crate which configures the global panic hook? |
bjorn3
commented
Mar 20, 2018
No problem |
emilyalbini
commented
Mar 26, 2018
Ping from triage @alexcrichton! The author pushed new commits, can you review them? @bjorn3, the build is failing because you didn't add the license header on the test. Can you add that? |
shepmaster
commented
Apr 7, 2018
Ping from triage, @alexcrichton ! |
alexcrichton
commented
Apr 7, 2018
ah I was still waiting on https://github.com/rust-lang/rust/pull/48702/files#r175140985 to be addressed |
bjorn3
commented
Apr 8, 2018
Sorry, forgot about that |
TimNN
commented
Apr 8, 2018
Your PR failed on Travis. Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Zoxc
commented
Apr 9, 2018
I don't like this approach, I much prefer my more robust and cleaner solution in #45637 which was rejected by the libs team for not being robust enough. |
emilyalbini
commented
Apr 16, 2018
Ping from triage @alexcrichton! The author addressed your comment! |
bjorn3
commented
Apr 16, 2018
@pietroalbini I have only partly addressed the comment, there is still a heap alloc. I haven't got time to fix it completely |
bjorn3
commented
Apr 16, 2018
Addressed the comment now. Ready for review @alexcrichton |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
rust-highfive
commented
Apr 18, 2018
Your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
alexcrichton
commented
Apr 24, 2018
Ah sorry for taking awhile to get back to this @bjorn3. I had forgotten about #47824 but I do agree with @Zoxc that it's best solution for now as it invovles far less guesswork and will hopefully be more robust over time. The reopening at #49825 only covers stack frames below the original "main frame" (aka binaries and tests). I think that there's possible work to be done after that lands to filter out the panic infrastructure in libstd (aka everything after the entry point to panics). Would you be interested in taking that on? |
bjorn3
commented
Apr 24, 2018
yes |

cc #47824