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

🐛 Explosive memory usage in GritQL parser #5032

Closed
1 task done
morgante opened this issue Feb 4, 2025 · 1 comment
Closed
1 task done

🐛 Explosive memory usage in GritQL parser #5032

morgante opened this issue Feb 4, 2025 · 1 comment
Labels
S-Needs triage Status: this issue needs to be triaged

Comments

@morgante
Copy link
Contributor

morgante commented Feb 4, 2025

Environment information

CLI:
  Version:                      0.0.1
  Color support:                true

Platform:
  CPU Architecture:             aarch64
  OS:                           macos

Environment:
  BIOME_LOG_PATH:               unset
  BIOME_LOG_PREFIX_NAME:        unset
  BIOME_CONFIG_PATH:            unset
  NO_COLOR:                     unset
  TERM:                         "xterm-256color"
  JS_RUNTIME_VERSION:           unset
  JS_RUNTIME_NAME:              unset
  NODE_PACKAGE_MANAGER:         unset

Biome Configuration:
  Status:                       Loaded successfully
  Formatter disabled:           false
  Linter disabled:              true
  Organize imports disabled:    true
  VCS disabled:                 true

Workspace:
  Open Documents:               0

What happened?

The biome parser consumes a massive (infinite?) amount of memory when parsing a simple GritQL pattern like this:

fn parse_language_declaration() {
    let code = "language js\n";
    let parse = parse_grit(code);
    assert!(parse.diagnostics().is_empty());
}

Notably this only happens in release builds, so it's somehow related to inlining/optimization.

Expected result

This pattern should be easily parseable without using much memory at all.

Code of Conduct

  • I agree to follow Biome's Code of Conduct
@morgante morgante added the S-Needs triage Status: this issue needs to be triaged label Feb 4, 2025
@morgante
Copy link
Contributor Author

morgante commented Feb 4, 2025

I'm planning to take a look / try to fix this, but I need to be careful with debugging to not trigger the memory usage myself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-Needs triage Status: this issue needs to be triaged
Projects
None yet
Development

No branches or pull requests

2 participants