Visual Studio Code - SonarLint Plugin - TypeScript: Error "eslint-bridge is unresponsive" during analysis

Get help SonarLint
, ,
#1

Hi , I am using SonarLint plugin - v1.18.0 for Visual Studio Code - 1.50.1,durning analysis I see below error in SonarLint Console.

[Error - 11:59:54.677] Failure during analysis, Node.js command to start eslint-bridge-bundle was: {NODE_PATH=c:\Program Files\Microsoft VS Code\resources\app\extensions\node_modules} C:\Users\I537607\scoop\apps\nvm\current\nodejs\nodejs\node.exe C:\Users\I537607.sonarlint\work.sonartmp_7074252071116539770\eslint-bridge-bundle\package\bin\server 62041
[Error - 11:59:54.678] java.lang.IllegalStateException: eslint-bridge is unresponsive

Even when I dont see this error in console, I see issue not being reported in SonarLint, but errors are reported in SonarQube. I see below in the logs in this case

[Debug - 11:55:04.425] ‘JavaScript analysis’ skipped because there is no related file in current project
[Debug - 11:55:04.426] Execute Sensor: TypeScript analysis
[Debug - 11:55:04.426] Skipping start of eslint-bridge server due to the failure during first analysis
[Debug - 11:55:04.426] Skipping execution of eslint-based rules due to the problems with eslint-bridge server
[Debug - 11:55:04.426] ‘PL/SQL Sensor’ skipped because there is no related file in current project
[Info - 11:55:04.427] Found 0 issue(s)

Node Version: v12.18.4

Logs attached.SonarLint.log (25.0 KB)

Thanks in advance.

#2

Hello, thank you for reporting this, and thanks especially for the detailed log output!

From what I see, it looks like the Language Server manages to start the ESLint bridge Node process, but then it has trouble communicating with it. We’ve had several reports of this in the past but never got enough information to troubleshoot thoroughly.

Here, as far as I understand, SonarQube is able to analyze the whole project, while SonarLint has trouble analyzing one file - is this correct?

This seems odd to me, since they use the very same analyzer under the hood. So there is probably something different between the 2 analysis methods.

  • What is the size of this project (in number of files and in NCLOC) as reported by SonarQube?
  • How many tsconfig.json files does it contain?
  • Do you have any configuration in your SonarQube analysis job? (custom properties, etc.)

Also, I noticed the first line of your log file:

[Error - 12:01:43.253] 14: 000001C266FDBF38

This looks suspiciously like the end of a memory dump. Could this be a memory dump from a crashed Node process?

#4

image

Project has only one tsconfig.json

My bad, I missed to notice at first place. Yes, its an memory dump, could this be a result of huge code base…? Do I need to increase the memory allocated to node…?

[Info - 12:01:32.715] Since SonarTS v2.0, TypeScript analysis is performed by SonarJS analyzer v6.0 or later. No TypeScript analysis is performed by SonarTS.

[Debug - 12:01:32.716] ‘JavaScript analysis’ skipped because there is no related file in current project

[Debug - 12:01:32.717] Execute Sensor: TypeScript analysis

[Error - 12:01:42.805] FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

[Error - 12:01:43.245] 1: 00007FF74EEA5F0F napi_wrap+114095

[Error - 12:01:43.246] 2: 00007FF74EE50B96 v8::base::CPU::has_sse+66998

[Error - 12:01:43.246] 3: 00007FF74EE51996 v8::base::CPU::has_sse+70582

[Error - 12:01:43.247] 4: 00007FF74F666E9E v8::Isolate::ReportExternalAllocationLimitReached+94

[Error - 12:01:43.248] 5: 00007FF74F64EF71 v8::SharedArrayBuffer::Externalize+833

[Error - 12:01:43.248] 6: 00007FF74F51B1DC v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1436

[Error - 12:01:43.248] 7: 00007FF74F526410 v8::internal::Heap::ProtectUnprotectedMemoryChunks+1312

[Error - 12:01:43.249] 8: 00007FF74F522F34 v8::internal::Heap::PageFlagsAreConsistent+3204

[Error - 12:01:43.250] 9: 00007FF74F518733 v8::internal::Heap::CollectGarbage+1283

[Error - 12:01:43.251] 10: 00007FF74F516DA4 v8::internal::Heap::AddRetainedMap+2452

[Error - 12:01:43.251] 11: 00007FF74F5380ED v8::internal::factory::NewFillerObject+61

[Error - 12:01:43.252] 12: 00007FF74F29E231 v8::internal::interpreter::JumpTableTargetOffsets::iterator::operator=+1665

[Error - 12:01:43.253] 13: 00007FF74FABB49D v8::internal::SetupIsolateDelegate::SetupHeap+546637

[Error - 12:01:43.253] 14: 000001C266FDBF38

#5

Thank you for the additional details.

It looks indeed like the Node process spawned to analyze JavaScript and TypeScript is running out of memory.

At 276k NCLOC, yes I believe this is a fairly large project :slight_smile: and still one that SonarLint should be able to handle gracefully.

Could you please try to add the following property in your user settings in VSCode? This should allow you to configure the maximum memory allocated to the Node process (the value is passed as --max-old-space-size when invoking Node):

{
  "sonarlint.analyzerProperties": {
    "sonar.javascript.node.maxspace": "2048"
  }
}

I used the block above to set the limit to 2048 MB on my developer box with 16GB of RAM, you might want to adjust to your machine’s available memory size.

#6

@JBL_SonarSource Thank you for suggestion the configuration to set maximum memory.

Observation, tried following option
max-old-space-size=2048 - failed
max-old-space-size=3072 - failed
max-old-space-size=4096 - failed, then noticed multiple open editors, closed all expect two(set workbench.editor.limit.value to 2 to ensure only two editors are open), analysis was complete with out memory dump, moment I switched between files, again resulted in head dump.

Finally set max-old-space-size=6144, again same problem, moment I switch between the files results in heap dump. Stopped here!

Attaching logs for the last dump - SonarLint.log (737.1 KB)

“sonarlint.analyzerProperties”: {
“sonar.javascript.node.maxspace”: “6144”
},

I think error message is not relevant once max head size id set beyond 4096.

[Error - 22:43:12.303] eslint-bridge Node.js process is unresponsive. This is most likely caused by process running out of memory. Consider setting sonar.javascript.node.maxspace to higher value (e.g. 4096).
[Error - 22:43:12.308] Failure during analysis, Node.js command to start eslint-bridge was: {NODE_PATH=c:\Program Files\Microsoft VS Code\resources\app\extensions\node_modules} C:\Users\I537607\scoop\apps\nvm\current\nodejs\nodejs\node.exe –max-old-space-size=6144

Q. Based on my observation. SonarLint clears the analysis results moment a file is closed. If I open the same file even without changes analysis is triggered? Why clear the report at first place? Why not analyze if there is only a change.? Is there a configuration to change this behavior?

#7

Thanks for the heads-up.

SonarLint indeed clears the analysis results when a file is closed.

This is done mainly for 2 reasons:

  • one is functional: to remove the file’s issues from the “Problems” pane
  • the other one is for performance: to free up memory on the Language Server.

This is not an issue for most languages and most projects, since our goal anyway is for single file analyses to take less than one second, to get a feedback as fast as possible in the IDE. We already noticed that TypeScript analysis can sometimes be slow (e.g a few seconds instead of a few hundreds of ms), however here I am really surprised how much it is struggling even with 6GB.

My hypothesis is that the ESlint bridge and/or the underlying TypeScript compiler might be hitting a performance hotspot on this project.

Would you be able to share it (privately) with us? This could help us investigate deeper whether the performance hotspot is within the TypeScript compiler or on one of the analyzer’s rules.

#8

Sorry, I cannot share the code. I got to know we have a Sonar dedicated team with in our organization, I am working with them to understand the problem. I will update you if we can get to root of the problem.

#9