Joel Höner

In any case, I think we should definitely add an env var that just disables all frame filtering in color-backtrace, for cases where false detects happen and to ease debugging...

Figured I might as well do it right away, here you go: https://github.com/athre0z/color-backtrace/commit/85b46b178d3a512d574bec587e1b8ad8c7882f56 I'll wrap this in a new release after we figured out whether there is an actual filtering...

Just realized: If this is a release (or otherwise non-O0 build, or the function has `#[inline(always)]`), another very possible option is that the `read_file` code has simply been inlined and...

Feel free to provide the binary with the frame not showing up so we can take a look at this on assembly level and determine whether the function has indeed...

While playing around with your binary on my Windows 10 VM, I noticed two different Windows specific issues: - The VT100 escape sequences are not evaluated - Also, a lot...

Back for more bad news: `read_file` is in fact not inlined and has a proper stack frame. Assuming that the backtrace is properly captured inside the function, I really don't...

> assuming it's not expensive it's probably best to put it at the top of the report fn, if it's expensive then I can put it in the new panic...

I considered it, but I refrained from doing it because I didn't want to pull in the required dependencies. I'd however accept it as a PR if it was implemented...

Currently, this is not supported. In which situations would you consider this useful? When no symbols are available?

I personally don't have much use for this, so it's somewhat unlikely that I'd add this myself. I tend to just attach a debugger for cases like this and `bt`...