I think I have found a worthwhile issue to report, but I don't know how to prove it

help
#1

So I am under the suspicion that one, some or all of

use std::future::Future;
use std::pin::Pin;
use std::task::{Context, Poll};

is breaking WASM if you optimize with either of these settings: --snip-rust-fmt-code --snip-rust-panicking-code

I'm pretty sure fmt and panicking code should be safe to strip out, if you don't want it in a production release.

So the problem is, how can I build a minimal WASM example that uses these structs (so they don't get optimized away), and then test it, so that I can identify the culprit and later report it?

#2

What do you mean by "breaking"? Can you show us a crash message or explain what you are seeing?

If stripping out the machinery for panicking and formatting causes your code to crash, there's a good chance that's because it's being used by your code. Can you get some sort of backtrace to see where it's being triggered?

#3

Hi

the error is in the JS console, that says, unreachable code.

I'm in a rush right now, but if you're curious, here is a mostly minimal example:


You need to put the generated wasm file in the same folder as this index.html: 
<html>
<head>
    <meta charset="utf-8">
    <title>TITLE</title>
    <style>
        html,
        body,
        canvas {
            margin: 0px;
            padding: 0px;
            width: 100%;
            height: 100%;
            overflow: hidden;
            position: absolute;
            background: black;
            z-index: 0;
        }
    </style>
</head>

<body>
    <canvas id="glcanvas" tabindex='1'></canvas>
    <!-- Minified and statically hosted version of https://github.com/not-fl3/miniquad/blob/master/native/sapp-wasm/js/gl.js -->
    <script src="https://not-fl3.github.io/miniquad-samples/gl.js"></script>
    <script>load("mini_async.wasm");</script> <!-- Your compiled wasm file -->
</body>

</html>

Then serve it to yourself.

Then run wasm-snip --snip-rust-fmt-code --snip-rust-panicking-code on it, and you'll get the error

1 Like
#4

wasm_snip replaces snipped code with unreachable, so if you hit this error with wasm_snip, but not without it, this means that you have some calls to fmt in your compiled code. I'm not sure why snipping panics triggers this too, however, since hitting the panic would result in an error, too.

#5

The log code seems to unconditionally get executed. This includes a format! usage.

#6

Hi @bjorn3, if you run the Miniquad library without the async modification you can wasm-snip without problem. As such, do you still believe that this is where the problem lies?

#7

I locally built it. After running wasm-snip the way you mentioned I looked for mentions of fmt in the disassembly created by wabt's wasm-objdump. This is what I found:

00ca94 func[56] <_ZN9sapp_wasm8sapp_run28_$u7b$$u7b$closure$u7d$$u7d$17hf29371c987adda1eE>:
[...]
00cb73: 10 5c                      | call 92 <_ZN5alloc3fmt6format17hb786be8f7eacdff5E>

Edit: that is the panic hook

#8

Found it. There is a dbg!() call leftover: https://github.com/Arifd/miniquad_async/blob/6889cd071a833859f7296a8a1a41f49f466817b7/src/main.rs#L50

1 Like
#9

Ah man! I feel so bad!! You're right! :man_facepalming: I even made a version of it that doesn't use the miniquad library at all just to test it.

I assumed dbg!() doesn't find its way into release builds??

1 Like
#10

No, dbg! is unconditional.

1 Like