`Runtime unreachable` when invoking `caml_fp_srs_b_poly_commitment` through the bindings layer

[Trivo25]

Invoking any method that that accesses caml_fp_srs_b_poly_commitment in the bindings layer causes an Runtime unreachable error

example:

method test_poly_commitment =
      let n = 131072 in
      let urs = Kimchi_bindings.Protocol.SRS.Fq.create n in
      let log_n = Core_kernel.Int.ceil_log2 n in
      let xs = Array.init log_n ~f:(fun _ -> Pasta_bindings.Fq.random ()) in
      Kimchi_bindings.Protocol.SRS.Fq.b_poly_commitment urs xs (* unreachable here *)

which invokes a rust function

            #[ocaml_gen::func]
            #[ocaml::func]
            pub fn [<$name:snake _b_poly_commitment>](
                srs: $name,
                chals: Vec<$CamlF>,
            ) -> Result<CamlPolyComm<$CamlG>, ocaml::Error> {
                let chals: Vec<$F> = chals.into_iter().map(Into::into).collect();
                let coeffs = b_poly_coefficients(&chals);
                let p = DensePolynomial::<$F>::from_coefficients_vec(coeffs);
                Ok(srs.commit_non_hiding(&p, None).into())
            }

logs

RuntimeError: unreachable
    at __rust_start_panic (wasm://wasm/00fc2ace:wasm-function[4410]:0x37a1a7)
    at rust_panic (wasm://wasm/00fc2ace:wasm-function[4071]:0x378aeb)
    at std::panicking::rust_panic_with_hook::hd6c4677d123a0b1c (wasm://wasm/00fc2ace:wasm-function[2799]:0x348596)
    at std::panicking::begin_panic_handler::{{closure}}::h4d615f37d8b95697 (wasm://wasm/00fc2ace:wasm-function[3372]:0x368838)
    at std::sys_common::backtrace::__rust_end_short_backtrace::h0c0583f19aa0b4d0 (wasm://wasm/00fc2ace:wasm-function[3987]:0x377d5b)
    at rust_begin_unwind (wasm://wasm/00fc2ace:wasm-function[3742]:0x373a58)
    at core::panicking::panic_fmt::hef457850cd9ff5e9 (wasm://wasm/00fc2ace:wasm-function[3923]:0x377070)
    at core::panicking::panic::hac9729efe1dbe352 (wasm://wasm/00fc2ace:wasm-function[3859]:0x375f5f)
    at caml_fq_srs_b_poly_commitment (wasm://wasm/00fc2ace:wasm-function[593]:0x1fd7c4)
    at Object.module.exports.caml_fq_srs_b_poly_commitment (/home/trivo/Development/mina-rollup/src/lib/snarkyjs/dist/node/_node_bindings/plonk_wasm.cjs:1102:14)
    at null.caml_fq_srs_b_poly_commitment (/workspace_root/src/lib/snarkyjs/src/bindings/kimchi/js/bindings.js:1094:15)
    at self (/workspace_root/src/lib/snarkyjs/src/bindings/ocaml/lib/snarky_js_bindings_lib.ml:1676:7)
    at null.caml_call_gen (/builtin/+stdlib.js:32:12)
    at Function.<anonymous> (/builtin/+jslib.js:289:12)
    at Function.Class.<computed> (/home/trivo/Development/mina-rollup/src/lib/snarkyjs/src/bindings/js/proxy.js:20:52)
    at file:///home/trivo/Development/mina-rollup/src/lib/snarkyjs/src/examples/program.tmp.js:4:26
    at ModuleJob.run (node:internal/modules/esm/module_job:198:25)
    at async Promise.all (index 0)
    at async ESMLoader.import (node:internal/modules/esm/loader:385:24)
    at async buildAndImport (file:///home/trivo/Development/mina-rollup/src/lib/snarkyjs/src/build/buildExample.js:12:22)
    at async file:///home/trivo/Development/mina-rollup/src/lib/snarkyjs/src/build/run.js:25:16

compiling smart contracts also invoked caml_fp_srs_b_poly_commitment. however, in that case it doesn't fail while in any other situation it does.

[L-as]

The function noted is in fact the incorrect one, the correct function is here.

The real issue, however, is that the thread pool is uninitialised. I figured this out after sprinkling the code with some console.logs.

The real real issue, however, is that no useful debugging information is contained within the error message. run_in_pool uses .unwrap() instead of .expect(...), but even when using the latter, the message, nor the line number, nor the (correct) stack trace is reported!

[L-as]

This is a symptom of console_error_panic_hook not being used, I made a PR to fix this completely: https://github.com/o1-labs/snarkyjs-bindings/pull/63

Previously it was set ad-hoc in some functions (I assume a relic of debugging the implementations).

[mitschabaude]

Nice find @L-as! At the time I introduced the console panic hook, I made it activate in those functions that would be the only important entry points for catching errors in snarkyjs