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

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

Closed
cceckman opened this issue Apr 27, 2022 · 3 comments
Closed

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

cceckman opened this issue Apr 27, 2022 · 3 comments
Labels
Milestone

Comments

@cceckman
Copy link
Contributor

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
Copy link
Contributor Author

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.

cceckman added a commit to cceckman/vscode-coverage-gutters that referenced this issue Apr 27, 2022
In ryanluker#364, I accidentally produced a file that (apparently) has empty
section filenames, as understood by the extension. This lead to an
undefined property access (`split`) when trying to work with the file
name; that exception propagated all the way up the rendering stack,
resulting in _no_ coverage being displayed.

With this change, if we encounter an error in `checkSection`, we just return
`false` - if it's an erroneous section, it doesn't apply to the current
file. (This is especially true if there is no `section.file` property!)

This way, we still show coverage wherever we can.
@ryanluker
Copy link
Owner

ryanluker commented May 1, 2022

@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 ryanluker added the bug label May 4, 2022
ryanluker added a commit that referenced this issue May 6, 2022
Address #364: catch errors per-section
@ryanluker ryanluker added this to the 2.10.0 milestone May 6, 2022
@ryanluker
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants