Sonar Java 4.6 goes into endless loop

[Bernd G.]

I'm using sonar-java-plugin-4.6.0.8784 with sonarqube-6.3-RC4.

With one project, I'm running into and endless loop on a single file, see the attached file with a anonymized log extract.

When switching back to sonar-java-plugin-4.4.0.8066, the project runs through without errors.

Any insights? Is this a known issue? Let me know if I should try to debug and deliver more details.

[Nicolas Peru]

Hi, 

Could you please share the file that's causing the issue ? Before debugging anything let's actually isolate the cause of the problem. 

Moreover, seems very strange to me to read in your log : 

WARN: Bytecode of dependencies was not provided for analysis of source files, you might end up with less precise results. Bytecode can 
be provided using sonar.java.libraries property

You may want to provide the classpath or your project to the analyzer to get better results. 

Cheers, 

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/076f7f54-4438-4552-ac72-ce01fc644cae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Nicolas PERU | SonarSource

Senior Developer
http://sonarsource.com

https://twitter.com/benzonico

[Bernd Götz]

I can't disclose source code from my side, unfortunately. If you tell me how to best debug it on my side, I am happy to provide you with the root cause analysis with that, not an issue. Pointers to documentation/settings appreciated.

On the byte code absense: We are deliberately analyzing source code only, without building/compiling the project, that's why it's not there.

[Nicolas Peru]

Hi, 

You may understand that helping you debug via email support is definitely not an efficient way to handle this. 

What you provided is too sparse to figure out what's going on. (I actually have no clue about what could be the cause of your problem). 

What I suggest is that you try to reduce the issue to a minimal example and then send this anonymized, reduced and self contained example. Privately eventually. That would be the best course of action IMO. 

We are definitely ready to help you out and gather feedback to improve SonarJava but that requires you to provide us some information. 

Regarding bytecode : you are basically missing out on a LOT of results here. Semantic analysis needs the bytecode to work properly and not providing it to the analyzer basically makes a lot of rule not really useful. 

HTH, 

Cheers, 

[Bernd Götz]

Hi Nicolas,

misunderstanding. I didn't request your online support for debugging, I just wanted to have some pointers how I can best debug my runner and provide you my feedback about that. I will now try to isolate the issue with that class only, and then provide you that one only in some way.

Regarding the missing bytecode topic: I am fully aware of what we're missing out here. It's just a special setup that we're using in this case.

Regards,

[Robert]

Hi all,

after upgrading the sonar-java-plugin from 4.4.0.8066  to 4.6.0.8784 we encountered also an "Endless Loop" analysing a project (no other changes on SonarQube, the SonarQube and build Configuration or the projects source code.

The SonarQube SonarQube Version used: 6.1
The analysis was triggered in a maven build using the sonar-maven-plugin 3.2.
Binaries are available to the sonar scanner, the maven log does not indicate any differences between the sonar analysis with the 4.4 and 4.6 verion of the sonar plugin until it starts to endlessly report:

14:32:19 [INFO] 38/102 files analyzed, current file: *************************.java

I am not allowed to disclose the original source code. Please find attached 3 stack traces recordef for the the main thread while looping.

While the loop occurss deterministicly in the original build, I was not able to reproduce it by extracting the above mentioned java source file with mocked dependencies which would allow me to provide an example after some further obfuscation and removal of the original logic in it.

Regards,
Robert

[Nicolas Peru]

Hi, 

I am actually investigating this very issue based on a concrete example (ie on a big source file). This seems to come from reporting where cross procedural reporting lacks a mechanism to break call cycles (cross procedural data flow has a mechanism to break those but not reporting). 

I still lack a minimal reproducer and struggle as well to reduce the case I have. So if you are able to provide a reduced example by looking at an obvious call cycle you may have in your calls (keep in mind that it can be a cycle that may never occur at runtime in your code but the analyzer may not "see it") that could be a great help. 

Cheers, 

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/0f7162b2-b54f-4a65-9245-dd5a1b5db511%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Nicolas Peru]

Hi here, 

I pinpoint the problem : https://jira.sonarsource.com/browse/SONARJAVA-2213 

Pretty tricky issue : call graph has to be quite big to reproduce it and in fact it is a performance problem not an infinite loop : because algorithm is doing a lot of useless operations. 

Fix should be available in version 4.8.

Cheers,