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

[pulsar-next] Main editor test suite crashing when run in its entirety #1205

Open
5 tasks done
savetheclocktower opened this issue Feb 9, 2025 · 0 comments
Open
5 tasks done
Labels
bug Something isn't working pulsar-next Related to the version of Pulsar that runs on the latest Electron

Comments

@savetheclocktower
Copy link
Contributor

Thanks in advance for your bug report!

  • Have you reproduced issue in safe mode?
  • Have you used the debugging guide to try to resolve the issue?
  • Have you checked our FAQs to make sure your question isn't answered there?
  • Have you checked to make sure your issue does not already exist?
  • Have you checked you are on the latest release of Pulsar?

What happened?

We're very close to having all of the editor tests pass in PulsarNext, but there's an out-of-memory crash happening in CI and locally that needs attending to.

Here's some representative output from a recent CI test run:

WASMTreeSitterLanguageMode > highlighting > injectionPoints and injectionPatterns > it terminates comment token at the end of an injection, so that the next injection is NOT a continuation of the comment [pass]
WASMTreeSitterLanguageMode > highlighting > injectionPoints and injectionPatterns > it only covers scope boundaries in parent layers if a nested layer has a boundary at the same position [pass]
WASMTreeSitterLanguageMode > highlighting > injectionPoints and injectionPatterns > it reports scopes from shallower layers when they are at the start or end of an injection [pass]
WASMTreeSitterLanguageMode > highlighting > injectionPoints and injectionPatterns > it respects the `includeChildren` property of injection points 
<--- Last few GCs --->

[18807:0x34b800590000]   904866 ms: Mark-Compact (reduce) 757.8 (812.4) -> 757.5 (791.4) MB, pooled: 0 MB, 216.68 / 0.00 ms  (average mu = 0.825, current mu = 0.000) last resort; GC in old space requested
[18807:0x34b800590000]   905017 ms: Mark-Compact (reduce) 757.5 (791.4) -> 757.5 (791.2) MB, pooled: 0 MB, 150.76 / 0.00 ms  (average mu = 0.736, current mu = 0.001) last resort; GC in old space requested


<--- JS stacktrace --->

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

Renderer process crashed - see https://www.electronjs.org/docs/tutorial/application-debugging for potential debugging information.
Renderer process crashed, exiting
error Command failed with exit code 100.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Error: Process completed with exit code 100.

You can see how close it gets to the end of the suite.

What's odd is how reliably this occurs locally, too, and seemingly in the same place. It happens to me whether I'm running the editor specs from the GUI or from the terminal. I can't even find evidence that the JS heap is too large — Activity Monitor on macOS doesn't report an obnoxious amount of memory usage, for instance.

When individual test suites are run in isolation locally, they pass (notwithstanding the small number of legit failures remaining).

Some things we could try:

  • See if it can be isolated to a single exacerbating test suite, or even a single test. You can see in the example I included that the crash happened in the middle of wasm-tree-sitter-language-mode-spec.js — which might implicate this as WASM-related or might just be coincidental.
  • See if there's a setting we can increase; the standard EXPORT NODE_OPTIONS="--max_old_space_size=8192" didn't seem to do anything for me, but maybe it needs to be something different in an Electron environment.
  • If nothing else, see if we can divide the editor tests into two separate jobs: one that tests the first half of the spec files and another that tests the second half. This will require some glob-savviness.

Pulsar version

PulsarNext 1.124.0

Which OS does this happen on?

❓ Other(Please specify in the OS details field below)

OS details

Multiple — observed in CI in both macOS and Windows

Which CPU architecture are you running this on?

Apple M-series

What steps are needed to reproduce this?

Run ATOM_JASMINE_REPORTER="list" yarn start --test spec

Additional Information:

No response

@savetheclocktower savetheclocktower added bug Something isn't working pulsar-next Related to the version of Pulsar that runs on the latest Electron labels Feb 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working pulsar-next Related to the version of Pulsar that runs on the latest Electron
Projects
None yet
Development

No branches or pull requests

1 participant