Skip to content
This repository was archived by the owner on Aug 25, 2025. It is now read-only.
This repository was archived by the owner on Aug 25, 2025. It is now read-only.

Sanity check - am I using this crate correctly? Doesn't seem to work for me for some reason when attempting to use with Vite #29

Description

@sortofsleepy

Summary

I have a workaround more or less; not for this issue exactly but it's just a way for me to keep working. Anyways I still wanted to ask out of curiosity.

I am trying to build a Vite plugin that loads a WASM module. I used the wasm-bindgen template as my starting point. In it, it provides a utils.rs file which declares

pub fn set_panic_hook() {
    // When the `console_error_panic_hook` feature is enabled, we can call the
    // `set_panic_hook` function at least once during initialization, and then
    // we will get better error messages if our code ever panics.
    //
    // For more details see
    // https://github.com/rustwasm/console_error_panic_hook#readme
    #[cfg(feature = "console_error_panic_hook")]
    console_error_panic_hook::set_once();
}

Currently when I attempt to use the function, I unfortunately am unable to get any specific error message/issue output from the console. I still see the general "unreachable" error and then a stack trace pointing to a memory location in the WASM module.

Even with a very simple test case like

pub fn process_file(){
    set_panic_hook();
    panic!("test");
}

I still get the general "unreachable" message.

Additional Details

Not sure if it might be the issue but maybe the issue lies somewhere in the interaction with Vite?

Thanks!

Activity

  1. ryanavella commented on Jan 15, 2024

    @ryanavella

    My problem may be unrelated as I'm not using Vite, but I'm seeing similar behavior.

    I am currently relying on the unstable build-std feature, and I noticed that if I remove these options from my .cargo/config.toml it fixes the issue.

     [unstable]
    -build-std = ["std", "panic_abort", "core", "alloc"]
    -build-std-features = ["panic_immediate_abort"]
     
     [build]
     rustflags = [
         "-Clto",
    -    "-Zvirtual-function-elimination",
     ]
     
     [profile.release]
     lto = true
     opt-level = 'z'
     debug = false
     codegen-units = 1
     panic = "abort"
     strip = true
     incremental = false

    I can maybe understand why the virtual-function-elimination feature needs to be removed, as it is experimental and may be eagerly removing a vtable that console_error_panic_hook is relying on. But I don't see why build-std options should matter at all, I would expect the panic hook to run before aborting.

  2. ryanavella commented on Jan 16, 2024

    @ryanavella

    @sortofsleepy After browsing the issue tracker a bit more, I've come to the conclusion that console_error_panic_hook is no longer maintained, along with several other repositories under the rustwasm organization.

    The merging of #21 is the last activity I see from @fitzgen in this repo, and their last 2-3 years of activity suggests they've been predominately tending to Bytecode Alliance crates. I don't see much (if any) activity in maintaining rustwasm organization crates. Note also that the WASM working group has no other active members.

    As for alternatives, I don't see any good candidates among the current forks. The crate is quite small however (~150 LOC) and is dual MIT/Apache licensed, so I suspect we are just waiting on a dedicated volunteer to either fork it, or somehow get in contact with the dev and take over ownership.

  3. sortofsleepy commented on Jan 17, 2024

    @sortofsleepy
    Author

    After browsing the issue tracker a bit more, I've come to the conclusion that console_error_panic_hook is no longer maintained, along with several other repositories under the rustwasm organization.

    Ah, oh well. Fortunately my use-case is non urgent but I would imagine yours and likely others aren't which is a little disappointing to hear.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    questionFurther information is requested

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions