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.

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

deno test --coverage generates invalid JSON in certain conditions that breaks deno coverage #12112

Closed
Tracked by #12826
kitsonk opened this issue Sep 17, 2021 · 8 comments
Closed
Tracked by #12826

deno test --coverage generates invalid JSON in certain conditions that breaks deno coverage #12112

kitsonk opened this issue Sep 17, 2021 · 8 comments
Labels
bug Something isn't working testing related to deno test and coverage

Comments

@kitsonk
Copy link
Contributor

kitsonk commented Sep 17, 2021

It seems that there is something going on. Take a look at https://github.com/oakserver/oak/pull/401/checks?check_run_id=3627766944#step:10:9 The emitted coverage is not readable by deno coverage.

I'm not sure when it started, as the CI hasn't run for a while on oak.

cc/ @caspervonb
@kitsonk kitsonk added bug Something isn't working testing related to deno test and coverage labels Sep 17, 2021
@kitsonk
Copy link
Contributor Author

kitsonk commented Sep 17, 2021

I ran it locally instead of CI:

> deno test --coverage=./cov --allow-read --allow-write --allow-net --unstable --jobs 4
... passes all tests ...
> deno coverage --unstable --lcov ./cov > cov.lcov
Check file:///Users/kitsonk/github/oak/application.ts
Check file:///Users/kitsonk/github/oak/helpers.ts
Check file:///Users/kitsonk/github/oak/middleware/proxy.ts
Check file:///Users/kitsonk/github/oak/mod.ts
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: BadJson(Error("invalid unicode code point", line: 1, column: 10377))', cli/tools/coverage.rs:217:60
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

@caspervonb
Copy link
Contributor

Reproducible, great! looking into it 🙂

@caspervonb
Copy link
Contributor

caspervonb commented Sep 17, 2021 •
edited

Thought this was unable to parse the raw coverage profiles but it's actually failing on SourceMap::from_slice https://github.com/denoland/deno/blob/main/cli/tools/coverage.rs#L217

Given the very long line it's safe to bet that this is from an inline source map and the source map itself is malformed.
Pretty sure this is a regression, to be continued after waking up.

@kitsonk
Copy link
Contributor Author

kitsonk commented Sep 17, 2021

So, sources are being embedded in the source map when tsc does the emit ("inlineSources" was set to true #11954). We need to investigate if the source map is actually malformed, or if it an "interpretation" of what is valid JSON somewhere along the line and figure out if it is tsc doing something bad or if it is sourcemap/serde_json not handling something properly.

Turning off the sources in source maps might seem like a quick fix, but it starts to impact the debugger experience, so we should find a way to fix it.

@c4spar
Copy link

c4spar commented Nov 1, 2021

I'm running into the same issue: https://github.com/c4spar/deno-dzx/runs/4074133401?check_suite_focus=true#step:5:6

It works with deno v1.13.2 but with deno >= v1.14.0 the deno coverage command fails.

Stacktrace

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: BadJson(Error("invalid unicode code point", line: 1, column: 6254))', cli/tools/coverage.rs:218:60
stack backtrace:
   0:        0x10f2f7a43 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h8d168763f08a78b9
   1:        0x10ebb96bc - core::fmt::write::h0fa46d4891ed63f1
   2:        0x10f2f593a - std::io::Write::write_fmt::hacbf9e10e17149ce
   3:        0x10f2f6b7f - std::panicking::default_hook::{{closure}}::hee7cf38dedfa76fc
   4:        0x10f2f5d4d - std::panicking::default_hook::hd12252412832a45f
   5:        0x10eb74651 - deno::setup_exit_process_panic_hook::{{closure}}::h080aa49274f758ea
   6:        0x10f2f57e9 - std::panicking::rust_panic_with_hook::h521fd09e07057893
   7:        0x10f313eea - std::panicking::begin_panic_handler::{{closure}}::h3588a5a9cca9e8e5
   8:        0x10f313e58 - std::sys_common::backtrace::__rust_end_short_backtrace::h86522c151a195ff9
   9:        0x10f313e00 - _rust_begin_unwind
  10:        0x110458c3f - core::panicking::panic_fmt::h8ab5bf5f27d0a26a
  11:        0x110458f25 - core::result::unwrap_failed::ha249df8fad19d4e8
  12:        0x10eb54873 - core::result::Result<T,E>::unwrap::hb5101728cf5b08f1
  13:        0x10eb53ab6 - <deno::tools::coverage::LcovCoverageReporter as deno::tools::coverage::CoverageReporter>::visit_coverage::h15a70e6a1922091d
  14:        0x10eb521b8 - deno::tools::coverage::cover_files::{{closure}}::h22b2d6d8c5ad2dbf
  15:        0x10eb4f4d6 - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h71f85db1ede00b4b
  16:        0x10e8180cf - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::hc88015e515d6c0a8
  17:        0x10e809145 - deno::main::ha40061d29520c905
  18:        0x10e804e2b - std::sys_common::backtrace::__rust_begin_short_backtrace::hce7f5943d45e8107
  19:        0x10e805087 - _main

@bartlomieju bartlomieju mentioned this issue Nov 20, 2021
Open
20 tasks
@bartlomieju
Copy link
Member

@kitsonk @c4spar could you confirm that your code had emojis in generated source maps when these panics were raised?

@c4spar
Copy link

c4spar commented Jan 11, 2022

yes, i can confirm the issue was an emoji in one of my files and the emoji is also in the generated source maps. It works after removing the emoji.

@bartlomieju
Copy link
Member

Thanks, then this is the same issue as #10936, I'm gonna close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working testing related to deno test and coverage
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@caspervonb @kitsonk @bartlomieju @c4spar