Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

'assertion failed: table.elements[idx].is_some()' when compiling with LTO #1264

Closed
nstoddard opened this issue Feb 16, 2019 · 2 comments
Closed

'assertion failed: table.elements[idx].is_some()' when compiling with LTO #1264

nstoddard opened this issue Feb 16, 2019 · 2 comments

Comments

@nstoddard
Copy link
Contributor

I have a project for which wasm-bindgen is failing when LTO is enabled:

> RUST_BACKTRACE=1 ./build-release.sh
thread 'main' panicked at 'assertion failed: table.elements[idx].is_some()', /home/nate/.cargo/registry/src/github.com-1ecc6299db9ec823/wasm-bindgen-cli-support-0.2.37/src/js/closures.rs:153:13
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:59
             at src/libstd/panicking.rs:211
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:491
   5: std::panicking::begin_panic
   6: wasm_bindgen_cli_support::js::closures::rewrite
   7: wasm_bindgen_cli_support::js::Context::finalize
   8: wasm_bindgen_cli_support::Bindgen::_generate
   9: wasm_bindgen::main
  10: std::rt::lang_start::{{closure}}
  11: std::panicking::try::do_call
             at src/libstd/rt.rs:59
             at src/libstd/panicking.rs:310
  12: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:102
  13: std::rt::lang_start_internal
             at src/libstd/panicking.rs:289
             at src/libstd/panic.rs:398
             at src/libstd/rt.rs:58
  14: main
  15: __libc_start_main
  16: _start

This works with wasm-bindgen 0.2.32 so it seems to have regressed since then. I haven't yet been able to find a small repro case; I can look into that more if it would be helpful.
@chinedufn
Copy link
Contributor

chinedufn commented Feb 16, 2019 •
edited
Loading

Thanks for the report!

In the last week wasm-bindgen made a big internal change that migrated away from parity-wasm in favor of walrus

Since then there have been a few issues that have popped up (for example #1254).

This is probably related to that.

I’m unsure of what the fix is but others have been squashing these bugs pretty quickly so we can wait on that.

alexcrichton added a commit to alexcrichton/wasm-bindgen that referenced this issue Feb 19, 2019
@alexcrichton
Fix an assert while deleting table elements
9bab9d4 
LLVM's mergefunc pass may mean that the same descriptor function is used
for different closure invocation sites even when the closure itself is
different. This typically only happens with LTO but in theory could
happen at any time!

The assert was tripping when we tried to delete the same function table
entry twice, so instead of a `Vec<usize>` of entries to delete this
commit switches to a `HashSet<usize>` which should do the deduplication
for us and enusre that we delete each descriptor only once.

Closes rustwasm#1264
@alexcrichton alexcrichton mentioned this issue Feb 19, 2019
Merged
@alexcrichton
Copy link
Contributor

@chinedufn is spot on, and this should be fixed at #1274. Thanks for the report @nstoddard!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@alexcrichton @chinedufn @nstoddard