MSBuild scans takes much longer since March 25

Ever since March 25 our MSBuild scans (the end part) is running endlessly, while before it took ~40 minutes - I wonder if there was a change in the MSBuild plugin around this date… Also tried to remove the tests/coverage part to see if it helps but we still see huge running time which wasn’t there prior to March 25… initially we just got an out-of-memory exception but then we’ve raised the xmx in SONAR_SCANNER_OPTS to higher limit and since it just runs forever…

The last messages in the log are:

    01:16:31 INFO: Sensor CSharpSecuritySensor [security]
    01:16:31 INFO: Reading type hierarchy from: Z:\Sources\Development\.sonarqube\out\ucfg_cs2
    01:16:33 INFO: Read 11680 type definitions
    01:16:33 INFO: Reading UCFGs from: Z:\Sources\Development\.sonarqube\out\ucfg_cs2
    01:16:55 INFO: 01:16:42.371 Building Type propagation graph
    01:16:55 INFO: 01:16:45.028 Running Tarjan on 560661 nodes
    01:16:56 INFO: 01:16:46.067 Tarjan found 556056 components
    01:16:58 INFO: 01:16:47.799 Variable type analysis: done
    01:16:59 INFO: Analyzing 64403 ucfgs to detect vulnerabilities.
    01:18:35 INFO: All rules entrypoints : 82 Retained UCFGs : 3934
    01:18:35 INFO: rule: S5131, entrypoints: 1
    01:18:35 INFO: Visited 4 ucfgs in 67 ms, 108 steps
    01:18:35 INFO: rule: S5131 done
    01:18:35 INFO: rule: S3649, entrypoints: 0
    01:18:35 INFO: Visited 0 ucfgs in 0 ms, 0 steps
    01:18:35 INFO: rule: S3649 done
    01:18:35 INFO: rule: S2076, entrypoints: 0
    01:18:35 INFO: Visited 0 ucfgs in 0 ms, 0 steps
    01:18:35 INFO: rule: S2076 done
    01:18:35 INFO: rule: S2091, entrypoints: 21
    01:18:50 INFO: Visited 1146 ucfgs in 16579 ms, 99673 steps
    01:18:50 INFO: rule: S2091 done
    01:18:50 INFO: rule: S2078, entrypoints: 0
    01:18:50 INFO: Visited 0 ucfgs in 0 ms, 0 steps
    01:18:50 INFO: rule: S2078 done
    01:18:50 INFO: rule: S2631, entrypoints: 12

Hi Roy,

On the 25th, 5 new security rules were deployed on SonarCloud along with a new version of “CSharpSecuritySensor” and that’s probably the reason of what you are observing.

Can you share a zip of the content of this directory Z:\Sources\Development.sonarqube\out\ucfg_cs2 and attach it here?

While we will look at the problem, I suggest that you deactivate the rule S2631 on which your scan is stuck. And do the same if the other rules that are executed after S2631 block your scan.


ok, so after removing both S2631 & S2083 my scan can now run…

Can’t add the attachement here but you can download it from here (without S2631) and here (also without S2083).

Can you please let me know when the issue is fixed so I can return to use the original Sonar Way? Also, is there a place to see such releases so I can understand if a certain sensor was updated at a certain date and understand we may have an issue with the sensor due to this change?

Thanks a lot for sharing this. I reproduced the issue on our latest development branch.

This seems to come from a method which has a lot of intermediary variables created for the purpose of vulnerability analysis.

would you be able to share (privately) the class FrmDBReparingWizard from the DBReparingWizard.cs (and more specifically the RepaireDatabase method ?

That would help us to understand the generated CFG.

Thanks a lot for your help.

Oh, and it is worth noting that another workaround besides deactivating the rule could be to exclude this file from the analysis : I managed to get the analysis to finish in a proper time by excluding this method from the analysis. This might be a nicer compromise than deactivating rules.

1 Like

Thanks, i’ll give it a try - didn’t know it was a matter of just one file…

The RepaireDatabase method is rather hell-ish, spreading over 2K lines even the scan says its Cognitive Complexity is 1413 (the Cyclomatic Complexity for the whole file is 1254) but if you want a potential nightmare i might be able to send it to a private mail address…

You can send it via the private message of this forum.