Slint 1.1.1 - Rust 1.72 -> thread 'main' has overflowed its stack

[csavels]

Hello,

I am using Slint 1.1.1 with Rust 1.72. I am coding with VSCode on Windows 11.

I have been testing a lot of things for 3 days now, without finding a solution, so I'd like to ask you a question.

Context:

• preview ui -> ok,
• cargo build --release -> ok
• cargo run -> "thread 'main' has overflowed its stack"

If I keep only the code

let ui = App::new().unwrap()
     ui.run();

of "fn main()" the application launches correctly.

If I add a single line of additional code (without a heavy task) -> "thread 'main' has overflowed its stack" again.

Do you have any advice? Thank you in advance.

[tronical]

It’s possible that we somehow regressed from #133. Could you try increasing the stack size as per https://users.rust-lang.org/t/stack-overflow-when-compiling-on-windows-10/50818/8 and see how much you need?

the stack size will depend on the complexity of the UI. Is it possible for you to attach a Slint file that reproduces this?

[tronical]

(I know. The error seems a little different, and after the new() call the UI should be on the heap. I still suspect it’s related)

[csavels]

Okay, you're just great! Next time I won't wait 3 days to ask and I'll contact you after 5 minutes ^^

This solved my problem: (from https://users.rust-lang.org/t/stack-overflow-when-compiling-on-windows-10/50818/8) I'm copying it here to make it easier for others to find the solution.

Create a folder in the root of your project directory called ".cargo" and then add a file to it called "config.toml". In that file you can set custom linker options:

# 64 bit MSVC
[target.x86_64-pc-windows-msvc]
rustflags = [
    "-C", "link-arg=/STACK:8000000"
]

# 64 bit Mingw
[target.x86_64-pc-windows-gnu]
rustflags = [
    "-C", "link-arg=-Wl,--stack,8000000"
]

Obviously, I restarted the IDE to be sure and now... everything works with "cargo run". I haven't tested the release but I assume it won't be affected.

Many thanks for your reply and the speed with which you answered me.

Edit:

Could you try increasing the stack size as per https://users.rust-lang.org/t/stack-overflow-when-compiling-on-windows-10/50818/8 and see how much you need?

If you need further information to assess the problem and counter it in your future releases, let me know how, I'll keep following this issue.

[csavels]

I tested quite a few values to get around the necessary value and it seems that the value "1500000" is more or less the necessary value.

[target.x86_64-pc-windows-msvc]
    1500000 -> ok
    1000000 -> crash

In terms of ui architecture, it's made up of several pages (5) with 0-2 sub-pages each.

Each page contains "table" (0-3) with dynamic models created from "Rectangle -> HorizontalLayout -> Rectangle -> TouchArea" (your "table" system doesn't work for me as it's missing an essential callback, I posted an issue about this before v1.1).

I hope you'll find this information useful.

[tronical]

Glad to hear that the workaround worked for you :)

Next time I won't wait 3 days to ask and I'll contact you after 5 minutes ^^

Feel free to also hop on our mattermost chat at https://chat.slint.dev/ :)

Regarding the stack size: 15MB is quite a lot. I really wonder where that comes from. Are you allocating anything else on the stack before the call to App::new().unwrap();? Do you also get a stack overflow if you add a line of code after the call to new()?

[csavels]

No, absolutely nothing is called before App::new. During my tests, I sometimes had to delete simple elements like "Text{}" without any attributes for the application to launch. Now everything works correctly.

The debug line relating to the crash often revolved around "vtable". At this stage, none of the ui models are fed, they are fed dynamically when the application pages are called.