ryanluker / vscode-coverage-gutters

Display test coverage generated by lcov and xml - works with many languages
https://marketplace.visualstudio.com/items?itemName=ryanluker.vscode-coverage-gutters
MIT License
460 stars 88 forks source link

Cannot read properties of undefined (reading 'split') #364

Closed cceckman closed 2 years ago

cceckman commented 2 years ago

With this lcov.info.gz file (uncompressed) in my repository, coverage-gutters provides the following output in the VS Code "output" pane- some initial output elided:

[1651035766179][coverageservice]: LOADING
[1651035767056][coverageservice]: Loading 1 file(s)
[1651035767056][coverageservice]: /home/cceckman/r/github.com/cceckman/peekatoo/coverage/gcs-70ed0f715011c5c7/lcov.info
[1651035767066][coverageservice]: Loaded 1 data file(s)
[1651035767342][coverageservice]: Caching 1200 coverage(s)
[1651035767342][coverageservice]: READY
[1651035767342][coverageservice]: RENDERING
[1651035767343][watchCoverageAndVisibleEditors]: Cannot read properties of undefined (reading 'split')
[1651035767343][watchCoverageAndVisibleEditors]: TypeError: Cannot read properties of undefined (reading 'split')
    at SectionFinder.resolveFileName (/home/cceckman/.vscode/extensions/ryanluker.vscode-coverage-gutters-2.9.1/out/src/coverage-system/sectionfinder.js:73:36)
    at SectionFinder.checkSection (/home/cceckman/.vscode/extensions/ryanluker.vscode-coverage-gutters-2.9.1/out/src/coverage-system/sectionfinder.js:53:38)
    at /home/cceckman/.vscode/extensions/ryanluker.vscode-coverage-gutters-2.9.1/out/src/coverage-system/sectionfinder.js:24:70
    at Array.filter (<anonymous>)
    at SectionFinder.findSectionsForEditor (/home/cceckman/.vscode/extensions/ryanluker.vscode-coverage-gutters-2.9.1/out/src/coverage-system/sectionfinder.js:24:45)
    at /home/cceckman/.vscode/extensions/ryanluker.vscode-coverage-gutters-2.9.1/out/src/coverage-system/renderer.js:32:54
    at Array.forEach (<anonymous>)
    at Renderer.renderCoverage (/home/cceckman/.vscode/extensions/ryanluker.vscode-coverage-gutters-2.9.1/out/src/coverage-system/renderer.js:25:21)
    at CoverageService.<anonymous> (/home/cceckman/.vscode/extensions/ryanluker.vscode-coverage-gutters-2.9.1/out/src/coverage-system/coverageservice.js:94:31)
    at Generator.next (<anonymous>)
    at fulfilled (/home/cceckman/.vscode/extensions/ryanluker.vscode-coverage-gutters-2.9.1/out/src/coverage-system/coverageservice.js:5:58)

I'm afraid I don't have a minimal-viable-reproducing example, but any of the lcov files I've managed to get out of this repository have the same stack trace. (Private repository so far- sorry! I've been trying to get a minimal reproducible example but no such luck yet.)

The lcov.info file above is generated from a Rust integration test binary (built with 1.60's new -C instr-coverage flag), then running the profraw file through llvm-profdata and llvm-cov. Same behavior with unit test binaries, though.


I'm afraid I'm not super familiar with debugging VS Code extensions - any pointers to help get the relevant information for this? (I see these docs and may be able to make some time to give it a try.)

Thanks for this lovely extension!

What's the best way for me to get more debug info on this?

cceckman commented 2 years ago

Managed to get this running under the VS code debugger. This seems to be landing in this function.

Stepping through, I see remoteLocalPaths is an empty array [] - I haven't configured the remotePathResolve property. But the debugger still seems to step into the branch that uses remoteLocalPaths; remoteFragment and localFragment are undefined, according to the debugger.

All that shakes out fine, oddly enough, for the first several iterations. Eventually, we hit an iteration where fileName is undefined. I see this in checkSection's first argument:

{
  lines: {
    found: 816,
    hit: 0,
    details: [
      {
        line: 283,
        hit: 0,
      },
      ... many more ...
    ],
  },
  functions: {
    hit: 0,
    found: 136,
    details: [
    ],
  },
  branches: {
    hit: 0,
    found: 0,
    details: [
    ],
  },
}

Bumping back up the stack to findSectionsForEditor, it looks like one of the sections (the last) has the property file: "/rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/thread/local.rs" - which isn't a real file on disk. But that doesn't look like it would apply in this case; here, we actually


Is the LCOV file ill-formed? (If so, I can take that up in Rust fora - I may not be putting it together properly!)

On the coverage-gutters side, is this the proper / most graceful way to handle this error? FWIW, the watch tooltip just reported "no coverage"; it didn't report a more verbose error, and none of the coverage showed from any file.

ryanluker commented 2 years ago

@cceckman Thank your for submitting a ticket and the evaluation of the issue!

I'm afraid I don't have a minimal-viable-reproducing example, but any of the lcov files I've managed to get out of this repository have the same stack trace. (Private repository so far- sorry! I've been trying to get a minimal reproducible example but no such luck yet.)

No worries on this front as even a ticket can be a good place for us to start looking at the issue 🤔.

I'm afraid I'm not super familiar with debugging VS Code extensions - any pointers to help get the relevant information for this? (I see these docs and may be able to make some time to give it a try.) Thanks for this lovely extension! What's the best way for me to get more debug info on this?

I am glad you enjoy the extension and were able to get the local debugging working (you were on the right track with the url above).

On the coverage-gutters side, is this the proper / most graceful way to handle this error? FWIW, the watch tooltip just reported "no coverage"; it didn't report a more verbose error, and none of the coverage showed from any file.

You are correct here that the error is producing a state where the extension sees the whole coverage as invalid (thus the no coverage mention in the tooltip). Ideally it should log the "bad" section and move along with consuming all the other good sections that are valid lcov... 🤔 .

I see you put up a PR as well so I can take a look there next!

ryanluker commented 2 years ago

I believe this has been fixed with #365 (Nice work there!).