Open juliankrieger opened 1 month ago
Hmm, your error does not seem to have a Backtrace field. IIRC the thiserror package requires that field in order to provide a backtrace?
I also don't have backtraces on panics.
Hmm then that's weird. Could you please follow the quickstart and get a brand new project, and see whether panic has stack traces?
Close since no response and it seems to not be directly related to frb (but a general rust question), but feel free to reopen if needed!
Not really fixed, I‘m on vacation until next week and can‘t add any information until then.
Take your time!
I can reproduce this bug.
My environment:
Steps:
flutter_rust_bridge_codegen create
write something that panics
diff --git a/rust/src/api/simple.rs b/rust/src/api/simple.rs
index 4360c82..d8bc331 100644
--- a/rust/src/api/simple.rs
+++ b/rust/src/api/simple.rs
@@ -1,6 +1,7 @@
#[flutter_rust_bridge::frb(sync)] // Synchronous mode for simplicity of the demo
pub fn greet(name: String) -> String {
- format!("Hello, {name}!")
+ // format!("Hello, {name}!")
+ panic!("panic")
}
#[flutter_rust_bridge::frb(init)]
RUST_BACKTRACE='full'
flutter run
which results in
thread '<unnamed>' panicked at src\api\simple.rs:1:1:
panic
stack backtrace:
0: 0x7ffdef373c48 - <unknown>
1: 0x7ffdef382749 - <unknown>
2: 0x7ffdef371ce1 - <unknown>
3: 0x7ffdef373a26 - <unknown>
4: 0x7ffdef375cf8 - <unknown>
5: 0x7ffdef375967 - <unknown>
6: 0x7ffdef2f2303 - <unknown>
7: 0x7ffdef2f6d25 - <unknown>
8: 0x7ffdef376257 - <unknown>
9: 0x7ffdef3760a9 - <unknown>
10: 0x7ffdef37433f - <unknown>
11: 0x7ffdef375d98 - <unknown>
12: 0x7ffdef388fe4 - <unknown>
13: 0x7ffdef2e193e - <unknown>
14: 0x7ffdef2e8336 - <unknown>
15: 0x7ffdef2e8254 - <unknown>
16: 0x7ffdef2ea11c - <unknown>
17: 0x7ffdef2e6b4a - <unknown>
18: 0x7ffdef2e99dd - <unknown>
19: 0x7ffdef2e33b1 - <unknown>
20: 0x7ffdef2e3783 - <unknown>
21: 0x7ffdef2e315b - <unknown>
22: 0x7ffdef2e42c1 - <unknown>
23: 0x7ffdef2e39b8 - <unknown>
24: 0x7ffdef2e695c - <unknown>
25: 0x7ffdef2e9a21 - <unknown>
26: 0x7ffdef2e32d6 - <unknown>
27: 0x7ffdef2e3783 - <unknown>
28: 0x7ffdef2e2f2b - <unknown>
29: 0x7ffdef2e42f1 - <unknown>
30: 0x7ffdef2e680e - <unknown>
31: 0x7ffdef2ec7e1 - <unknown>
32: 0x7ffdef2ecaae - <unknown>
33: 0x7ffdef2e718d - <unknown>
34: 0x27be3906c8f - <unknown>
35: 0x27bef065709 - <unknown>
36: 0x27bef065214 - <unknown>
37: 0x27bef06509f - <unknown>
38: 0x27be4e5fe06 - <unknown>
39: 0x27bef0634a6 - <unknown>
40: 0x27bef062fb0 - <unknown>
41: 0x27bef06283b - <unknown>
42: 0x27bef06255c - <unknown>
43: 0x27bef05f19b - <unknown>
44: 0x27bef038ee6 - <unknown>
45: 0x27bef0384b7 - <unknown>
46: 0x27bef037760 - <unknown>
47: 0x27bef0370af - <unknown>
48: 0x27bef0368a6 - <unknown>
49: 0x27bef035824 - <unknown>
50: 0x27bef034c47 - <unknown>
51: 0x27bef038879 - <unknown>
52: 0x27bef037760 - <unknown>
53: 0x27bef0370af - <unknown>
54: 0x27bef0368a6 - <unknown>
55: 0x27bef035824 - <unknown>
56: 0x27bef034c47 - <unknown>
57: 0x27bef038879 - <unknown>
58: 0x27bef05a4bb - <unknown>
59: 0x27bef037760 - <unknown>
60: 0x27bef0370af - <unknown>
61: 0x27bef0517b6 - <unknown>
62: 0x27bef0368a6 - <unknown>
63: 0x27bef035824 - <unknown>
64: 0x27bef034c47 - <unknown>
65: 0x27bef038879 - <unknown>
66: 0x27bef037760 - <unknown>
67: 0x27bef0370af - <unknown>
68: 0x27bef0368a6 - <unknown>
69: 0x27bef035824 - <unknown>
70: 0x27bef034c47 - <unknown>
71: 0x27bef038879 - <unknown>
72: 0x27bef037760 - <unknown>
73: 0x27bef0370af - <unknown>
74: 0x27bef0368a6 - <unknown>
75: 0x27bef035824 - <unknown>
76: 0x27bef034c47 - <unknown>
77: 0x27bef04b262 - <unknown>
78: 0x27bef03f34b - <unknown>
79: 0x27bef035824 - <unknown>
80: 0x27bef034c47 - <unknown>
81: 0x27bef038879 - <unknown>
82: 0x27bef037760 - <unknown>
83: 0x27bef0370af - <unknown>
84: 0x27bef0368a6 - <unknown>
85: 0x27bef035824 - <unknown>
86: 0x27bef034c47 - <unknown>
87: 0x27bef033bf5 - <unknown>
88: 0x27bef031ee7 - <unknown>
89: 0x27bef031d77 - <unknown>
90: 0x27bef02f22b - <unknown>
91: 0x27bef02d26f - <unknown>
92: 0x27bef02cc9c - <unknown>
93: 0x27bef02c671 - <unknown>
94: 0x27bef02c54a - <unknown>
95: 0x27bef02c46d - <unknown>
96: 0x27bef02bab2 - <unknown>
97: 0x27bef02a4ac - <unknown>
98: 0x27bef02a239 - <unknown>
99: 0x27be4e2163d - <unknown>
100: 0x27be4e20e4c - <unknown>
101: 0x27be3902f9f - <unknown>
102: 0x7ffdb7a27852 - InternalFlutterGpu_Texture_AsImage
103: 0x7ffdb7a29666 - InternalFlutterGpu_Texture_AsImage
104: 0x7ffdb7a46a3f - InternalFlutterGpu_Texture_AsImage
105: 0x7ffdb7a6c592 - InternalFlutterGpu_Texture_AsImage
106: 0x7ffdb7a6c70d - InternalFlutterGpu_Texture_AsImage
107: 0x7ffdb80d4bff - InternalFlutterGpu_Texture_AsImage
108: 0x7ffdb795caf3 - InternalFlutterGpuTestProc
109: 0x7ffdb795cc4b - InternalFlutterGpuTestProc
110: 0x7ffdb79c6f11 - InternalFlutterGpuTestProc
111: 0x7ffdb732589c - InternalFlutterGpuTestProc
112: 0x7ffdb732fb16 - InternalFlutterGpuTestProc
113: 0x7ffdb73257b3 - InternalFlutterGpuTestProc
114: 0x7ffdb7329e00 - InternalFlutterGpuTestProc
115: 0x7ffdb7329c0c - InternalFlutterGpuTestProc
116: 0x7ffdb82677c2 - InternalFlutterGpu_Texture_AsImage
117: 0x7ffe4355257d - BaseThreadInitThunk
118: 0x7ffe449caf28 - RtlUserThreadStart
Hmm, could you please firstly check,
Hmm, could you please firstly check,
* are you building rust in debug mode or release mode? (need to be debug, or release-with-symbols) * could you please check whether your windows exe (or dll or whatever) contains the rust symbols?
I'm not sure how the rust code is built since the building process is managed by frb and flutter and I don't find how to configure it.
However, I have set profile.release.debug = true
and added code to check cfg debug_assertions
, which shows the code is built in debug mode .
diff --git a/rust/Cargo.toml b/rust/Cargo.toml
index e6e9502..cd79081 100644
--- a/rust/Cargo.toml
+++ b/rust/Cargo.toml
@@ -8,3 +8,6 @@ crate-type = ["cdylib", "staticlib"]
[dependencies]
flutter_rust_bridge = "=2.1.0"
+
+[profile.release]
+debug = true
diff --git a/rust/src/api/simple.rs b/rust/src/api/simple.rs
index 4360c82..8e5967c 100644
--- a/rust/src/api/simple.rs
+++ b/rust/src/api/simple.rs
@@ -1,6 +1,9 @@
#[flutter_rust_bridge::frb(sync)] // Synchronous mode for simplicity of the demo
pub fn greet(name: String) -> String {
- format!("Hello, {name}!")
+ // format!("Hello, {name}!")
+ #[cfg(debug_assertions)]
+ println!("in debug mode");
+ panic!("panic")
}
#[flutter_rust_bridge::frb(init)]
As for symbols, could you give a guide on how to check them?
As for symbols, could you give a guide on how to check them?
I do not have windows at hand and different platforms differ. Usually just google about that. For linux it is e.g. nm and objdump.
As for symbols, could you give a guide on how to check them?
I do not have windows at hand and different platforms differ. Usually just google about that. For linux it is e.g. nm and objdump.
Here's the result of dumpbin out.txt
It seems that the debug symbols are stored in the pdb file, as with other executables compiled with msvc toolchains.
BTW, my rust toolchain is:
active toolchain
----------------
stable-x86_64-pc-windows-msvc (default)
rustc 1.79.0 (129f3b996 2024-06-10)
It seems that the debug symbols are stored in the pdb file
Great, then if the symbols are there, then maybe rust does not find it?
This is a general Rust question instead of specific to frb I guess. So maybe search "rust + windows" or "rust + flutter + windows" and see whether there are some discussions about symbolication.
Another way is that, since it gives you addresses (0x7ffdef373c48 etc; but may need conversion), and you have pdb file, then you can symbolicate using that pdb file and the address manually (via some commands or scripts).
Yet another way is to use libraries like Sentry to handle symbol files.
Great, then if the symbols are there, then maybe rust does not find it?
This is a general Rust question instead of specific to frb I guess. So maybe search "rust + windows" or "rust + flutter + windows" and see whether there are some discussions about symbolication.
However, a regular rust program prints useful stack trace on panic even in release mode. So I think it has something to do with frb, particularly the building process which may differ from a simple cargo build
.
Another way is that, since it gives you addresses (0x7ffdef373c48 etc; but may need conversion), and you have pdb file, then you can symbolicate using that pdb file and the address manually (via some commands or scripts).
Yet another way is to use libraries like Sentry to handle symbol files.
I would try it if we can't get rust to find the symbols.
particularly the building process which may differ from a simple cargo build.
Yes I think so. Maybe also ask on Cargokit repo, because frb uses that to compile rust inside a flutter project.
particularly the building process which may differ from a simple cargo build.
Yes I think so. Maybe also ask on Cargokit repo, because frb uses that to compile rust inside a flutter project.
Their example repo also fails to print meaningful stacktrace. Will report the issue to them.
Cargokit should copy the pdb file alongside the dll, but that doesn't seem to be happening for some reason. Maybe an issue with cmake integration. You could try to find the appropriate PDB files in the build directory and copy them next to final executable - do you get stacktrace then?
Cargokit should copy the pdb file alongside the dll, but that doesn't seem to be happening for some reason. Maybe an issue with cmake integration. You could try to find the appropriate PDB files in the build directory and copy them next to final executable - do you get stacktrace then?
the pdb file is together with the executable and dlls when they are built.
Here's the structure:
ls
Directory: D:\files\code\stkt\build\windows\x64\runner\Debug
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 2024/8/9 21:37 data
-a--- 2024/7/18 9:00 45005824 flutter_windows.dll
-a--- 2024/8/9 21:37 957952 rust_lib_stkt.dll
-a--- 2024/8/9 21:37 570368 stkt.exe
-a--- 2024/8/9 21:37 7532544 stkt.pdb
BTW, I checked the rust_lib_stkt.dll
file and noticed this section
Debug Directories
Time Type Size RVA Pointer
-------- ------- -------- -------- --------
66B61B98 cv 2A 000BD07C BBE7C Format: RSDS, {5322EE7E-8C22-4F36-88A8-50260010C2D1}, 1, rust_lib_stkt.pdb
66B61B98 feat 14 000BD0A8 BBEA8 Counts: Pre-VC++ 11.00=142, C/C++=24, /GS=24, /sdl=0, guardN=23
66B61B98 coffgrp 304 000BD0BC BBEBC
so I copied stkt.pdb
to rust_lib_stkt.pdb
and ran .\stkt.exe
, but it still does not work.
dump of rust_lib_stkt.dll
rust_lib_stkt.txt
There should be rust_lib_stkt.pdb
somewhere in the build directory. stkt.pdb
is the pdb for final executable.
There should be
rust_lib_stkt.pdb
somewhere in the build directory.stkt.pdb
is the pdb for final executable.
In fact there are 3:
fd rust_lib_stkt.pdb .\build\
.\build\windows\x64\plugins\rust_lib_stkt\Debug\rust_lib_stkt.pdb
.\build\windows\x64\plugins\rust_lib_stkt\cargokit_build\x86_64-pc-windows-msvc\debug\deps\rust_lib_stkt.pdb
.\build\windows\x64\plugins\rust_lib_stkt\cargokit_build\x86_64-pc-windows-msvc\debug\rust_lib_stkt.pdb
However, none of them worked when I copied them to the exectuable's directory.
TBF I'm not sure what Rust is doing on Windows to symbolicate the stacktrace. I looked now at some of my C++ code where I need to symbolicate stacktraces and I noticed that I had to manually append executable path to IDebugClient
in order to resolve the PDB file next to executable. So maybe Rust is not doing that. Or is not even using dbgeng.dll
to symbolicate the stacktrace. Would need to look into that.
Briefly looking at backtrace-rs implementation, it seems like it should be doing the same thing...
Describe the bug
Things I tried:
RUST_BACKTRACE=1
(and making sure it's set)backtrace
feature forflutter_rust_bridge
My error structs look like this:
I return an anyhow::Result with the error inside using the
?
syntax.Am I missing something?
Steps to reproduce
-
Logs
Expected behavior
No response
Generated binding code
No response
OS
No response
Version of
flutter_rust_bridge_codegen
No response
Flutter info
No response
Version of
clang++
No response
Additional context
No response