Stack trace still entirely `unknown` even after following documentation entirely

[juliankrieger]

Describe the bug

Things I tried:

• enabling backtraces via RUST_BACKTRACE=1 (and making sure it's set)
• Enabling the backtrace feature for flutter_rust_bridge

My error structs look like this:

use core::error;

use axum::{http::header::ToStrError, response::{IntoResponse, Response}};
use thiserror::Error;
use tracing::event;
#[derive(Error, Debug)]
pub enum ServerError {
    #[error("Bad Request")]
    BadRequest,

    #[error("Bad Request - Reason: {0}")]
    BadRequestWithReason(String),

    #[error("Bad Response - Reason: {0}")]
    BadResponse(String),


    #[error(transparent)]
    OpensslError {
        #[from]
        source: openssl::error::ErrorStack,
    },

    #[error(transparent)]
    JWSError(#[from] josekit::JoseError),

    //#[error("Internal crate error. Please report this issue.")]
    #[error(transparent)]
    InternalError{
        #[from]
        source: anyhow::Error,
    },
    //#[error("Internal BRSKI crate error")]
    #[error(transparent)]
    BRSKIError(#[from] brski_prm_artifacts::error::BRSKIPRMError),

    #[error("Not Acceptible")]
    NotAcceptible,

    #[error("Unsupported Media Type")]
    UnsupportedMediaType,

    #[error(transparent)]
    ReqwestError {
        #[from]
        source: reqwest::Error,
    },

    #[error(transparent)]
    IoError(#[from] std::io::Error),
    
    #[error(transparent)]
    ToStrError(#[from] ToStrError),

    #[error(transparent)]
    SerdeError(#[from] serde_json::Error),
}


}

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

[fzyzcjy]

Hmm, your error does not seem to have a Backtrace field. IIRC the thiserror package requires that field in order to provide a backtrace?

[juliankrieger]

I also don't have backtraces on panics.

[fzyzcjy]

Hmm then that's weird. Could you please follow the quickstart and get a brand new project, and see whether panic has stack traces?

[fzyzcjy]

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!

[juliankrieger]

Not really fixed, I‘m on vacation until next week and can‘t add any information until then.

[fzyzcjy]

Take your time!

[snylonue]

I can reproduce this bug.

My environment:

• windows: 10.0.22631.3880
• flutter: 3.22.3
• frb: 2.1.0
• rust: rustc 1.79.0 (129f3b996 2024-06-10) stable-x86_64-pc-windows-msvc

Steps:

1. create a new project with flutter_rust_bridge_codegen create
2. 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)]

3. set RUST_BACKTRACE='full'
4. 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

[fzyzcjy]

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?

[snylonue]

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?

[fzyzcjy]

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.

[snylonue]

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)

[fzyzcjy]

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.

[snylonue]

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.

[fzyzcjy]

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.

[snylonue]

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.

[knopp]

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?

[snylonue]

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

[knopp]

There should be rust_lib_stkt.pdb somewhere in the build directory. stkt.pdb is the pdb for final executable.

[snylonue]

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.

[knopp]

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.

[knopp]

Briefly looking at backtrace-rs implementation, it seems like it should be doing the same thing...

[fzyzcjy]

Close this issue since this is not a bug of flutter_rust_bridge, but something related to Rust + Windows (+ Flutter). I add some doc to point to this for future readers though.

Feel free to reopen / create another issue to discuss if there is anything new!

[github-actions[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new issue.