Open fzyzcjy opened 2 years ago
I don't understand what you are doing... You backtrace before you call silly_function
, no?
@s1341 Sure! That is the strange thing. silly_function should NOT affect my backtrace printing. But it indeed does!
I want to say, even doing such a seemingly unrelated thing, can cause frames to disappear.
Thanks for the reply!
silly_function
is going to cause a stack overflow (or an i32
overflow, not sure which will come first) which will cause a panic which will dump a backtrace. That backtrace is not going to be using your code though... It's the standard panic backtrace. No?
Ah? It does not cause any stack overflows imho. I use rand
so indeed it terminates after several times of recursion. (btw I write that simply because I want to do something that will not be optimized away by compiler)
I don't know then. I get backtraces when just using Backtrace::new
even on release builds on aarch64 android 11.
I am on armv7 (32bit). But rust should support this imho.
I get backtraces when just using Backtrace::new even on release builds on aarch64 android 11.
Have your app released to the market - i.e. I wonder whether it is ok on one phone, or ok on various kinds of phones (various version, etc)?
I'm not writing an app. I'm mostly running tools via shell (adb). I get backtraces on a few different phones.
Ah... Thanks
repo: https://github.com/fzyzcjy/flutter_rust_bridge/blob/experiment-backtrace/frb_example/with_flutter/README.md (note: it is of this commit https://github.com/fzyzcjy/flutter_rust_bridge/commit/8ec9751a04c006caeaf4b66172689b1625a16360 , if you wonder)
Please ignore those readme and other unrelated code in that example. The only useful code is only dozens of lines.
Run it on android: https://github.com/fzyzcjy/flutter_rust_bridge/blob/experiment-backtrace/frb_example/with_flutter/run_android.sh
rust/api.rs::off_topic_debug_throw
sets up log and env variable (just some normal things), then call off_topic_code::print_backtrace_wrapper
print_backtrace_wrapper
calls print_backtrace
(both in off_topic_code.rs
)print_backtrace
calls backtrace::trace
and logs it.However, looking at the code below, the print_backtrace
function itself is completely disappeared.
I know this minimal reproducible sample is not as special ("add lines of code and frames disappear"), but I cannot reproduce that on this repo (can only reproduce "frames disappear").
All right... I guess it is problem of inline. Adding #[inline(never)]
seems to solve the problem. Not sure, need more checks. Wait a bit.
Hm. Isn't "inlining can trash your backtraces" a known problem?
EDIT: For a smaller example, see a commit below. I have added a small example that you can run.
Hi thanks for this lib! Yesterday's solution work pretty well, but then I encounter a problem. Sometimes, the stack is complete. However, it only works for some of my code, while the rest of my code cannot output full backtrace but missing many frames. An extreme example is shown below - even if I only add some dummy code that is useless, the stack trace is incomplete, and the frames of my crate just disappears completely. I mean, the unwinding step has problems - since the function address itself just disappears completely.
This is very annoying and I cannot use backtrace-rs at all in production environment if it just output no frames that I need... Any help is appreciated!
RUSTFLAGS="-Cforce-unwind-tables"
but no change.@kjvalencik Hi could you please give some suggestions? Thanks! May also related: @bjorn3 @alexcrichton Not sure whether this is in your field; could you please also give some suggestions? Thanks!
For example, my old function:
yields stack trace (just focus on the stack trace itself, ignore other noise; the log is folded)
However, with following:
it becomes:
With the dummy function, but in debug mode: it works