[SOLVED] Compiled binarie work / don't work

#1

Hello,

I’m French and my english is… not good.

I’m a newcomer in Rust World
I’ve make a little game with Rust and Piston and after a lot (not so much) of difficulty, I succeed.
But… (yes there is a “but”) on my PC(Windows 64bits), where i’ve compiled this game, the binarie work well, and on an another PC(windows and 64 bits too) the game crash directly.
I don’t understand why it don’t work, the compiler don’t show any warning or error…

On a third PC (Windows 64bits), we’ve got this message :
“thread ‘main’ panicked at ‘called ‘Result::unwrap()’ on an ‘Err’ value : NotFound’, libcore\result.rs:1009:5”

Thnks a lot for any help

1 Like

#2

Have you tried running a debug binary with RUST_BACKTRACE=1 environment variable set? That should give you a cleaner (more accurate) backtrace and perhaps you can see which Result is being unwrapped.

0 Likes

#3

Thanks for your reply.

I’ve set RUST_BACKTRACE = 1 on each PC, I’ve runned the debug binary, but nothing…

0 Likes

#4

What is the game trying to accomplish? Opening a graphics context, opening a window etc?

0 Likes

#5

A PistonWindow with event (update, render, key pressed and released). Pick some png in assets folder and move themon the screen, controling mouvement of one of them with keyboard, writing some text (with a ttf font in the assets folder) on the screen… Very classical :-/

On the second computer, when the game try to run, the window (white background + title ok) is briefly open and closed.

But I don’t understand why the game work on the first computer (with no error message or warning) and don’t on the second a third computer

I hope i’m clear ?!?

0 Likes

#6

Perhaps it’s a graphics card implementation detail? There could be compile time shader/GPU program compilation which could perhaps not be acceptable?

0 Likes

#7

How are you setting your RUST_BACKTRACE? Its need to be compiled with this flag, not run, so try something like: RUST_BACKTRACE=1 cargo run. It has to print you backtrace, and point you to exact failing line. Without this, you need to guess which unwrap() causes a problem. I am pretty sure, that Piston doesn’t unwraps things internally. According to “NotFound” Result description I am pretty sure, that the problem is some resource missing on filesystem, or path mismatch.

0 Likes

#8

@OptimisticPeach
So, if GPU or shader cause this problem, perhaps it will be intersting to switch with Piston engine from crate piston_window to glutin_window ?
I’ve tested the “getting started” example of Piston on Github and it run well on all PC of mine and this example use glutin_window instead piston_window.

@hashdone
I’ve tested RUST_BACKTRACE = 1 when i use cargo run, but it return nothing else… no backtrace

0 Likes

#9

On Windows you need to use set to set the env variables. Something like

set RUST_BACKTRACE=1
cargo run

Are you already doing like this?

0 Likes

#10

Yes.
The backtrace work well with another code,.
But, with my game, it return nothing (on the 3 PC)

0 Likes

#11

Do you use any unsafe?

If you are using some unsafe, maybe it could be that you are triggering some kind of UB. And it is possible that your stack is smashed. And your dragons are laying eggs :yum:.

1 Like

#12

Instead of unwrap(), use expect(“msg”) with a different “msg” for each expect(). That will tell you which unwrap() is causing the panic. (By the way, your English is far better than my French.)

1 Like

#13

@dodomorandi
Hummm scramble dragons eggs !
Rust is know to be safe and if Rust compiler think that my code is safe for one computer, why, this same code will be unsafe on two other computer. All this 3 pc are Windows 64bits.

@alanhkarp
Thanks for compliment
And thanks for the tips, i will replace all my unwrap() in main() by expect(“some different message”) and try it

1 Like

#14

You are totally right about Rust safeness… until an unsafe function/unsafe block creates an unsound behaviour. But judging from your answer, I assume you are not touching the ‘u’-word :wink:

One simple approach is to follow @alanhkarp’s suggestion. Another way is to run gdb or lldb, b rust_panic and use the debugger to get your stacktrace.

The reason I initially hypothesized some sort of UB (oh, it is totally normal to get different behaviours from the same code in these cases) is because of the strange situation. But it is also possible that something is playing with the environment variables a bit too much. If you find where the code panics, you could also try to print the envs just before the unwrap and see if RUST_BACKTRACE is still there.

1 Like

#15

Yes it’s true. For the moment, it’s like chinese for me :blush:

But Great News, i’ve followed @alanhkarp 's suggestion. After a ton of expect(“with some funny message inside”) the evil unwrap who make my game panic is appear… A dark story of Deadly Path.

So this path problem is now solve . All is running.

Thanks a lot to all member of this community who have spent a few time to help a poor RustyNewbie

5 Likes

TWiR quote of the week
closed #16

This topic was automatically closed after 34 hours. New replies are no longer allowed.

0 Likes