Recursion limit reached when using vec of tuples

[mdtusz]

Description

I'm submitting a question:

Starting with an application that builds with no errors using cargo web deploy --release, when changing a field in a struct from listing: Vec<Entry> to listing: Vec<(Entry, bool)> the following error occurs:

$ RUST_BACKTRACE=full cargo web deploy -p the_app
   Compiling the_app v0.1.0 (/home/miklos/Code/my_app/the_app)
thread 'main' panicked at 'failed to parse cargo output: Error("recursion limit exceeded", line: 1, column: 25485)', src/libcore/result.rs:1084:5
stack backtrace:
   0:     0x55fcdeee4ee2 - backtrace::backtrace::libunwind::trace::he8b122396753abc9
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.35/src/backtrace/libunwind.rs:88
   1:     0x55fcdeee4ee2 - backtrace::backtrace::trace_unsynchronized::h18fe1998c04a41d4
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.35/src/backtrace/mod.rs:66
   2:     0x55fcdeee4ee2 - std::sys_common::backtrace::_print::habdbb4fd9d9c0917
                               at src/libstd/sys_common/backtrace.rs:47
   3:     0x55fcdeee4ee2 - std::sys_common::backtrace::print::hb1a087501dbb63e0
                               at src/libstd/sys_common/backtrace.rs:36
   4:     0x55fcdeee4ee2 - std::panicking::default_hook::{{closure}}::h24dac8a570d8db04
                               at src/libstd/panicking.rs:200
   5:     0x55fcdeee4bc6 - std::panicking::default_hook::h893744b6a334a746
                               at src/libstd/panicking.rs:214
   6:     0x55fcdeee5635 - std::panicking::rust_panic_with_hook::h86238c539b0cb6f7
                               at src/libstd/panicking.rs:477
   7:     0x55fcdeee51d2 - std::panicking::continue_panic_fmt::h40d8b593540103a4
                               at src/libstd/panicking.rs:384
   8:     0x55fcdeee50c6 - rust_begin_unwind
                               at src/libstd/panicking.rs:311
   9:     0x55fcdef073ea - core::panicking::panic_fmt::hd39929f6b65962b9
                               at src/libcore/panicking.rs:85
  10:     0x55fcdef074e7 - core::result::unwrap_failed::hba83d9a1c7cbeac2
                               at src/libcore/result.rs:1084
  11:     0x55fcde9507af - cargo_web::cargo_shim::BuildConfig::launch_cargo::hd9480118abca0cfb
  12:     0x55fcde950ec3 - cargo_web::cargo_shim::BuildConfig::build_internal::ha17125cf4e453047
  13:     0x55fcde94e7a1 - cargo_web::cargo_shim::BuildConfig::build::h09de474c85374d8f
  14:     0x55fcde7ff992 - cargo_web::build::Project::build_or_check::h5f1e7cfe4f9fea2a
  15:     0x55fcde87b2a8 - cargo_web::cmd_deploy::command_deploy::h2cab495cb49775f7
  16:     0x55fcde90c4f2 - cargo_web::run::h956ef2abc5adc4e9
  17:     0x55fcde7d4e20 - cargo_web::main::h882f7166863b526a
  18:     0x55fcde7cf4a3 - std::rt::lang_start::{{closure}}::h37d1f28b3af34129
  19:     0x55fcdeee5063 - std::rt::lang_start_internal::{{closure}}::h2d73454cf270e050
                               at src/libstd/rt.rs:49
  20:     0x55fcdeee5063 - std::panicking::try::do_call::h77a4575cf788f31b
                               at src/libstd/panicking.rs:296
  21:     0x55fcdeeef6ba - __rust_maybe_catch_panic
                               at src/libpanic_unwind/lib.rs:80
  22:     0x55fcdeee5bed - std::panicking::try::h52f0ea554a05d17e
                               at src/libstd/panicking.rs:275
  23:     0x55fcdeee5bed - std::panic::catch_unwind::h79d7d184f78cd1c9
                               at src/libstd/panic.rs:394
  24:     0x55fcdeee5bed - std::rt::lang_start_internal::hf6771be4bf884153
                               at src/libstd/rt.rs:48
  25:     0x55fcde7d4ff2 - main
  26:     0x7fad40dacee3 - __libc_start_main
  27:     0x55fcde7cc07e - _start
  28:                0x0 - <unknown>
thread 'main' panicked at 'failed printing to stdout: Broken pipe (os error 32)', src/libstd/io/stdio.rs:792:9
stack backtrace:

Even setting the recursion_limit to ridiculously high values does not seem to fix this - there must be infinite recursion somehow, but I'm unsure of how to debug what or where this may come from.

I've encountered recursion issues in the past as well but typically they are from the html! macro and can be avoided by restructuring the view, but I can't seem to solve this one.

Context (Environment)

• Rust: rustc 1.39.0-nightly

• yew: v0.8.0
• stdweb: v0.4.18

• target: wasm32-unknown-unknown

• cargo-web: 0.6.26

[jstarry]

Interesting, does this happen for you on rust stable?

[mdtusz]

Yep - same issue on stable. This is on the component struct for a component only 1 level down from the top-level component too.

[jstarry]

@mdtusz Dang, that's not good. Do you think you could put together a minimal example showing this issue? That would be the quickest way to getting this fixed

[mdtusz]

Yep. I'll try to reproduce it in a small toy example. It is pretty strange though because I can create a vec of tuples in other places - just not in this one component struct.

Any hints for ways to inspect more under-the-hood for this? I'm still relatively new to rust so don't know all the debug tricks yet.

[godadada]

I got same error here with latest cargo:

thread 'main' panicked at 'failed to parse cargo output: Error("recursion limit exceeded", line: 1, column: 39083)', src/libcore/result.rs:1084:5
stack backtrace:
0: 0x55f9cd5a8dfb - backtrace::backtrace::libunwind::trace::h89fcc71e59e3bc5b
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.34/src/backtrace/libunwind.rs:88
1: 0x55f9cd5a8dfb - backtrace::backtrace::trace_unsynchronized::h0bad9be1379e729a
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.34/src/backtrace/mod.rs:66
2: 0x55f9cd5a8dfb - std::sys_common::backtrace::_print::hd3382a1f33c473da
at src/libstd/sys_common/backtrace.rs:47
3: 0x55f9cd5a8dfb - std::sys_common::backtrace::print::h0ec6f03cfb8e76a6
at src/libstd/sys_common/backtrace.rs:36
4: 0x55f9cd5a8dfb - std::panicking::default_hook::{{closure}}::h96cbf7b454e3f557
at src/libstd/panicking.rs:200
5: 0x55f9cd5a8ad6 - std::panicking::default_hook::h95a8f00337383d83
at src/libstd/panicking.rs:214
6: 0x55f9cd5a956d - std::panicking::rust_panic_with_hook::h92f98b46e22f14ed
at src/libstd/panicking.rs:477
7: 0x55f9cd5a90f2 - std::panicking::continue_panic_fmt::h25abfbb4e5b7043a
at src/libstd/panicking.rs:384
8: 0x55f9cd5a8fd6 - rust_begin_unwind
at src/libstd/panicking.rs:311
9: 0x55f9cd5cbccd - core::panicking::panic_fmt::h7e9f94035af782b3
at src/libcore/panicking.rs:85
10: 0x55f9cd5cbdc7 - core::result::unwrap_failed::hf7591c1dd9412006
at src/libcore/result.rs:1084
11: 0x55f9cd00a712 - cargo_web::cargo_shim::BuildConfig::launch_cargo::h52ad42de8a275f34
12: 0x55f9cd00aec0 - cargo_web::cargo_shim::BuildConfig::build_internal::he1797115f3a10735
13: 0x55f9cd008731 - cargo_web::cargo_shim::BuildConfig::build::h46a9e9d1f3e3605d
14: 0x55f9cceb10d9 - cargo_web::build::Project::build_or_check::h8bbe42c562628cc5
15: 0x55f9ccfc12c4 - cargo_web::cmd_build::command_build_or_check::h84a84f3c990bf2f3
16: 0x55f9ccfc32ee - cargo_web::run::h52c4c32bc5cf0f28
17: 0x55f9cce8610d - cargo_web::main::h906d67cf23fa185c
18: 0x55f9cce7f1f3 - std::rt::lang_start::{{closure}}::hdf763c575ab2059c
19: 0x55f9cd5a8f73 - std::rt::lang_start_internal::{{closure}}::h4e93c1949c7a1955
at src/libstd/rt.rs:49
20: 0x55f9cd5a8f73 - std::panicking::try::do_call::h9440ccd4dc467eaa
at src/libstd/panicking.rs:296
21: 0x55f9cd5b367a - __rust_maybe_catch_panic
at src/libpanic_unwind/lib.rs:80
22: 0x55f9cd5a9b3d - std::panicking::try::hc046e7ee42ee744f
at src/libstd/panicking.rs:275
23: 0x55f9cd5a9b3d - std::panic::catch_unwind::h27dfc457c200aee0
at src/libstd/panic.rs:394
24: 0x55f9cd5a9b3d - std::rt::lang_start_internal::hea1b49a567afe309
at src/libstd/rt.rs:48
25: 0x55f9cce86302 - main
26: 0x7fb9a5255b6b - __libc_start_main
27: 0x55f9cce7c06a - _start
28: 0x0 -

[mdtusz]

As far as I can tell, this seems to be resolved in 0.9.2. I couldn't seem to make a minimal reproduction case either, but just changing the version number and recompiling solved the issue.

[jstarry]

Interesting, well glad to hear it's no longer an issue! @godadada if you are still experiencing this issue, feel free to reopen

[dmit]

So I also encountered this issue (with yew 0.9.2) and here's what I was able to dig up. In the error message

failed to parse cargo output: Error("recursion limit exceeded", line: 1, column: <large number>)

the failed to parse cargo output part comes from cargo-web: src/cargo_shim/mod.rs#L823;
and the recursion limit exceeded part comes from serde, which is used to parse the JSON-encoded output of cargo proper.

After adding more logging to that part of cargo-web, the reason for the error turned out to be prosaic: in my project a typo in the use of the html! {} macro resulted in a 350KB JSON message describing the error. The bulk of the message comes from a deeply nested structure that looks like this:

  "message": {
    "message": "this close tag has no corresponding open tag",
    "code": null,
    "level": "error",
    "spans": [
      {
        <...>
        "expansion": {
          "span": {
            "file_name": "<::proc_macro_nested::count macros>",
            <...>
            "expansion": {
              "span": {
                "file_name": "<::proc_macro_nested::dispatch macros>",
                <...>
                "expansion": {
                  "span": {
                    "file_name": "<::proc_macro_nested::dispatch macros>",
                    <...>

This goes on for 157 levels, and as far as I can tell serde sets its recursion limit to 128 by default. Thus the panic in cargo-web.

The good news is that the root cause of the problem (HTML syntax error inside an html! {} block in my code) is included in the error message. The bad news is that it's buried under a lot of information that doesn't seem to be critical. One possible solution would be to have cargo-web disable the recursion limit in serde (via the unbounded_depth crate feature), but that seems like treating the symptom to me.

---

tl;dr for end-users: If you see the failed to parse cargo output: Error("recursion limit exceeded" error when running cargo-web, double check for malformed markup or any type errors inside your html! {} blocks.

[dmit]

Here's a minimal example to reproduce the problem: https://github.com/dmit/yew-recursion-limit