Emscripten support broken: missing function: emscripten_set_mousemove_callback / assertion failed: validate_hidpi_factor(dpi_factor) #760
Comments
|
Can you find out the value of As for the other stuff, um... @Osspial are you still interested in doing work on Emscripten? |
|
I could if I had to, but I've already got a whole bunch of non-web stuff I'd like to work on and I'd rather avoid adding anything else to the pile if I can. There seems to be plenty of people that are interested in having Emscripten work, though. It's probably worth putting out requests for help on the Reddit and the user forums to see if any of those people would be interested in working on it. |
|
I might be willing to help maintain the Emscripten support, if I can get it working first...
Agreed this could be a promising direction of investigation. I'll look into it, but another confounding factor seems to be the Rust compiler version. emsdk 1.37.12 + rustc 1.31.0 hits this Upgrading rustc to 1.32.0 fails compilation with rustup default 1.31.0
rustup target install wasm32-unknown-emscripten
emsdk install sdk-1.38.16-64bit
emsdk activate sdk-1.38.16-64bit
source ~/emsdk/emsdk_env.sh
EMCC_DEBUG=1 cargo build --example window --target wasm32-unknown-emscripten |
|
Adding logging in validate_hidpi_factor() shows that dpi_factor is 2, but is failing because dpi_factor.is_normal() is false. --- a/src/dpi.rs
+++ b/src/dpi.rs
@@ -83,6 +83,7 @@
/// otherwise, you risk panics.
#[inline]
pub fn validate_hidpi_factor(dpi_factor: f64) -> bool {
+ panic!("dpi_factor = {}, is_sign_positive={}, is_normal={}", dpi_factor, dpi_factor.is_sign_positive(), dpi_factor.is_normal());
dpi_factor.is_sign_positive() && dpi_factor.is_normal()
}thread 'main' panicked at 'dpi_factor = 2, is_sign_positive=true, is_normal=false', src/dpi.rs:86:5 https://doc.rust-lang.org/nightly/std/primitive.f64.html#method.is_normal documents is_normal as follows:
dpi_factor.classify() confirms this number is https://stackoverflow.com/questions/8341395/what-is-a-subnormal-floating-point-number explains the bit representation of subnormals.
minimal test case: fn main() {
let x = 2.0f64;
panic!("x={}, is_sign_positive={}, is_normal={}, classify={:?}, to_bits=0x{:x}, ==2.0={}",
x, x.is_sign_positive(), x.is_normal(), x.classify(),
x.to_bits(),
x == 2.0);
}rustc 1.32.0 + emscripten sdk-1.38.22-64bit: rustc 1.31.0 + emscripten sdk-1.37.12-64bit: so, |
iceiix
changed the title
|
If I remove the is_normal check: --- a/src/dpi.rs
+++ b/src/dpi.rs
@@ -83,7 +83,7 @@
/// otherwise, you risk panics.
#[inline]
pub fn validate_hidpi_factor(dpi_factor: f64) -> bool {
- dpi_factor.is_sign_positive() && dpi_factor.is_normal()
+ dpi_factor.is_sign_positive()
}
/// A position represented in logical pixels.then the window example can load on rustc 1.31.0 + emscripten sdk-1.37.12-64bit without error, and moving the mouse logs WindowEvents/DeviceEvents as expected. So far, so good! Would still be a good idea to find out what is going on with winit on latest versions, rustc 1.32.0 + emscripten sdk-1.38.22-64bit causing |
rustc 1.32.0 + emscripten sdk-1.38.22-64bit: thread 'main' panicked at 'x=2, is_sign_positive=true, is_normal=true, classify=Normal, to_bits=0x4000000000000000, ==2.0=true', normaltest.rs:3:5 rustc 1.31.0 + emscripten sdk-1.37.12-64bit: thread 'main' panicked at 'x=2, is_sign_positive=true, is_normal=false, classify=Subnormal, to_bits=0x4000000000000000, ==2.0=true', normaltest.rs:3:5 rust-windowing#760 (comment) rust-windowing#760 (comment)
|
I believe the missing function incompatibility is caused by the use of To fix this, winit could switch to the _on_thread replacement functions they are defined to, as juj points out: https://github.com/emscripten-core/emscripten/blob/443447b14d34a3d710d33f229dea64e5c78a78ce/system/include/emscripten/html5.h#L483-L494 Was about to file a bug to rust-lang/rust before realizing this, I'll save the text here since it may be useful for the small repro case: https://gist.github.com/iceiix/94083aa0025471f37557466e836a4e8d |
francesca64
added
B - bug
|
Because emscripten support has been replaced with |
Is winit compatible with emscripten sdk 1.38.22? When running the examples I'm getting this error, interested if anyone else is seeing it, or if it is a misconfiguration on my end:
window.js:7196 missing function: emscripten_set_mousemove_callback
window.js:7196 missing function: emscripten_set_mousemove_callback
_emscripten_set_mousemove_callback @ window.js:7196
__ZN5winit8platform8platform6Window3new17h036fa7310bcbf823E @ grisu.rs:491
dynCall_viii @ grisu.rs:491
Module.dynCall_viii @ window.js:7835
invoke_viii @ window.js:7510
__ZN5winit6window38__LT_impl_u20_winit__WindowBuilder_GT_5build17h500b3e62957b8a6fE @ grisu.rs:491
dynCall_viii @ grisu.rs:491
Module.dynCall_viii @ window.js:7835
invoke_viii @ window.js:7510
__ZN6window4main17h6c9df911c3ebf060E @ grisu.rs:491
__ZN3std2rt10lang_start28__u7b__u7b_closure_u7d__u7d_17hc3810b9cbdf76d05E @ grisu.rs:491
__ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17h45d765e0ad7e854fE @ grisu.rs:491
__ZN3std9panicking3try7do_call17he4712eb84191fb3bE_llvm_369D5A5A @ grisu.rs:491
dynCall_vi @ grisu.rs:491
Module.dynCall_vi @ window.js:7823
invoke_vi @ window.js:7477
___rust_maybe_catch_panic @ grisu.rs:491
__ZN3std2rt19lang_start_internal17h76f990c2b2c74932E @ grisu.rs:491
__ZN3std2rt10lang_start17h018a6e635825245eE @ grisu.rs:491
_main @ grisu.rs:491
Module._main @ window.js:7739
callMain @ window.js:7973
doRun @ window.js:8031
run @ window.js:8045
runCaller @ window.js:7950
removeRunDependency @ window.js:1462
receiveInstance @ window.js:1624
receiveInstantiatedSource @ window.js:1649
Promise.then (async)
doNativeWasm @ window.js:1665
Module.asm @ window.js:1751
(anonymous) @ window.js:7556
window.js:8131 -1
window.js:8132 -1
abort @ window.js:8132
_emscripten_set_mousemove_callback @ window.js:7196
__ZN5winit8platform8platform6Window3new17h036fa7310bcbf823E @ grisu.rs:491
dynCall_viii @ grisu.rs:491
Module.dynCall_viii @ window.js:7835
invoke_viii @ window.js:7510
__ZN5winit6window38__LT_impl_u20_winit__WindowBuilder_GT_5build17h500b3e62957b8a6fE @ grisu.rs:491
dynCall_viii @ grisu.rs:491
Module.dynCall_viii @ window.js:7835
invoke_viii @ window.js:7510
__ZN6window4main17h6c9df911c3ebf060E @ grisu.rs:491
__ZN3std2rt10lang_start28__u7b__u7b_closure_u7d__u7d_17hc3810b9cbdf76d05E @ grisu.rs:491
__ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17h45d765e0ad7e854fE @ grisu.rs:491
__ZN3std9panicking3try7do_call17he4712eb84191fb3bE_llvm_369D5A5A @ grisu.rs:491
dynCall_vi @ grisu.rs:491
Module.dynCall_vi @ window.js:7823
invoke_vi @ window.js:7477
___rust_maybe_catch_panic @ grisu.rs:491
__ZN3std2rt19lang_start_internal17h76f990c2b2c74932E @ grisu.rs:491
__ZN3std2rt10lang_start17h018a6e635825245eE @ grisu.rs:491
_main @ grisu.rs:491
Module._main @ window.js:7739
callMain @ window.js:7973
doRun @ window.js:8031
run @ window.js:8045
runCaller @ window.js:7950
removeRunDependency @ window.js:1462
receiveInstance @ window.js:1624
receiveInstantiatedSource @ window.js:1649
Promise.then (async)
doNativeWasm @ window.js:1665
Module.asm @ window.js:1751
(anonymous) @ window.js:7556
window.js:311 warning: build with -s DEMANGLE_SUPPORT=1 to link in libcxxabi demangling
warnOnce @ window.js:311
demangle @ window.js:1051
(anonymous) @ window.js:1060
demangleAll @ window.js:1058
stackTrace @ window.js:1085
abort @ window.js:8142
_emscripten_set_mousemove_callback @ window.js:7196
__ZN5winit8platform8platform6Window3new17h036fa7310bcbf823E @ grisu.rs:491
dynCall_viii @ grisu.rs:491
Module.dynCall_viii @ window.js:7835
invoke_viii @ window.js:7510
__ZN5winit6window38__LT_impl_u20_winit__WindowBuilder_GT_5build17h500b3e62957b8a6fE @ grisu.rs:491
dynCall_viii @ grisu.rs:491
Module.dynCall_viii @ window.js:7835
invoke_viii @ window.js:7510
__ZN6window4main17h6c9df911c3ebf060E @ grisu.rs:491
__ZN3std2rt10lang_start28__u7b__u7b_closure_u7d__u7d_17hc3810b9cbdf76d05E @ grisu.rs:491
__ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17h45d765e0ad7e854fE @ grisu.rs:491
__ZN3std9panicking3try7do_call17he4712eb84191fb3bE_llvm_369D5A5A @ grisu.rs:491
dynCall_vi @ grisu.rs:491
Module.dynCall_vi @ window.js:7823
invoke_vi @ window.js:7477
___rust_maybe_catch_panic @ grisu.rs:491
__ZN3std2rt19lang_start_internal17h76f990c2b2c74932E @ grisu.rs:491
__ZN3std2rt10lang_start17h018a6e635825245eE @ grisu.rs:491
_main @ grisu.rs:491
Module._main @ window.js:7739
callMain @ window.js:7973
doRun @ window.js:8031
run @ window.js:8045
runCaller @ window.js:7950
removeRunDependency @ window.js:1462
receiveInstance @ window.js:1624
receiveInstantiatedSource @ window.js:1649
Promise.then (async)
doNativeWasm @ window.js:1665
Module.asm @ window.js:1751
(anonymous) @ window.js:7556
window.js:7993 exception thrown: abort(-1) at Error
at jsStackTrace (http://localhost:1235/window.js:1066:13)
at stackTrace (http://localhost:1235/window.js:1083:12)
at abort (http://localhost:1235/window.js:8142:44)
at _emscripten_set_mousemove_callback (http://localhost:1235/window.js:7196:63)
at __ZN5winit8platform8platform6Window3new17h036fa7310bcbf823E (wasm-function[431]:1924)
at dynCall_viii (wasm-function[1281]:17)
at Object.Module.dynCall_viii (http://localhost:1235/window.js:7835:40)
at invoke_viii (http://localhost:1235/window.js:7510:27)
at __ZN5winit6window38__LT_impl_u20_winit__WindowBuilder_GT_5build17h500b3e62957b8a6fE (wasm-function[182]:510)
at dynCall_viii (wasm-function[1281]:17)
To build:
This creates window.js and .wasm in target/wasm32-unknown-emscripten/debug/examples/, to load I added this file test.html in that directory, following the requirements outlined in https://github.com/tomaka/winit#emscripten-and-webassembly:
then served the files through a simple Python web server:
visited http://localhost:1234/test.html in Chrome, then I received the
window.js:7196 missing function: emscripten_set_mousemove_callbackerror in the JavaScript debugger.Searching for this error message finds only one issue: emscripten-core/emscripten#7525 Emscripten 1.38.17+ incompatible with upstream SDL 2.0.8, slightly different situation, that user was able to resolve their problem by rebuilding. However I reinstalled the SDK,
cargo clean, cleared out ~/.emscripten_cache, so I'm not sure what else I would need to rebuild?Next I tried to build on a completely different system (Ubuntu Linux in a VM, first system was macOS 10.14.2) to isolate whether there was a stale misconfiguration with emscripten or something, but with the same emsdk 1.38.22, it failed even earlier, on
cargo build --example window --target wasm32-unknown-emscriptencompilation:With an earlier emscripten 1.37.12 installation on macOS 10.14.2, I could build but running would fail with yet a different error:
thread 'main' panicked at 'assertion failed: validate_hidpi_factor(dpi_factor)', .cargo/registry/src/jackfan.us.kg-1ecc6299db9ec823/winit-0.18.0/src/dpi.rs:236:9
https://github.com/tomaka/winit/blob/master/src/dpi.rs#L236
assuming this was an incompatibility fixed in newer emsdk, I updated to 1.38.22, but then hit the error described above. I see #548 "DPI for everyone" changed this code last, but the author couldn't get anything to run in the browser.
Is there a known-working compatible version of emsdk I should use? Any help appreciated
The text was updated successfully, but these errors were encountered: