Recently we upgraded our SONAR from 3.x to 4.3. There was an error in our Jenkins build (squidindex was null) which triggered the upgrade of the java from 2.2 to 2.2.1 along with the plugins for JaCoCo, Findbugs, Squid for Java, and Surefire.
Once SonarQube was up and running again, we discovered that although no code changes had taken place, we now had over 200 critical issues as well as a high number of major ones. Upon research, it became apparent that all of our previously marked false-positives had now reappeared.
Obviously we want to find a way to fix this besides walking through over a thousand various issues and re-marking them.
We have done some research in the database and have discovered a puzzle that we think might be related. In the Issues table, we have found that there are duplicate entries where the first difference is that one entry has the simple file name and the other entry has the file name along with the extension.
(I had an image of a few lines from the database to put here, but as I do not yet have a 10 reputation, I cannot. Please contact me and I will be glad to email the image. Sigh.)
As you can see, Lines 2 & 3 both refer to line 134 in the file PersistentObjectCollection.java. Line 2 shows that the issue is FIXED and CLOSED while Line 3 shows the same issue as Open and null resolution.
We are wondering if we could safely use SQL to find matched pairs like this and copy the necessary columns across to register the issues properly?
Can you please take a look and tell me if this is something feasible to do, or if there is a better alternative to try.
Question already asked on the SonarQube mailing list : http://sonar.markmail.org/thread/kpx3une24lwoilli
Please don't duplicate question !!
Related
We have an issue since our upgrade to SonarQube 6.0 that on the issues page the link icon or the right arrow icon no longer link to the code.
In this case clicking either link takes you to another (smaller) list of issues.
This is not the case for all issues, the only difference I can spot is that on the problem issues the filename and line number are not shown. checking in the database and in the issues table the 'line' column is also null.
We are using SonarQube 6.0 with C# plugin 5.3.2 - Analysis is triggered by TFS2015 Update 3
Many thanks in advance for any ideas/advice.
Following Teryk's response I manage fine tune my investigation. It turns out that it is cased by the MSBUILD output which does not include a filename or line for certain CA warning is Microsoft.Design and Microsoft.Naming, e.g. CA1024, CA1040, CA1704, CA1716, thus:
3>MSBUILD : warning CA1040: Microsoft.Design : Define a custom attribute to replace 'ITierRepository'.
When this happens the issue is recorded against the solution but obviously cannot be assign to a specific file and the line not identified.
Having found that I was quick able to find the article which discusses the same issue:
https://groups.google.com/d/topic/sonarqube/UDIIjWbCGjs
It is caused by the fact that FxCop is not able find source for the issue as described here:
https://blogs.msdn.microsoft.com/codeanalysis/2007/05/12/faq-why-is-file-and-line-information-available-for-some-warnings-in-fxcop-but-not-for-others/
It apparently relates to changes to FxCop reporting that were introduced in v5.2 of the C# plugin which was also deployed at the same time as upgrading to SQ 6.0
I am using Sonar 4.5.5, and I tried to use manual metrics in filters. No luck, also not with the ones provided by default. I searched the archives and Stackoverflow and Jira for that, nothing. Any insights?
Edit: The same behavior applies to version 5.1.2, justed tried that out today.
Never mind, I found out why Sonar behaves like this!
After creating a measurement, it takes another analysis run to activate the measurements. The 'Manual Measures' dialog of any project tells me that in bold letters: "Pending measures are marked with orange box. Their values will be integrated to project during next analysis.". Maybe my question and answer helps others to be faster with this.
Whilst coding a fun new trash can for a Minecraft server network that I develop for, I came across a pretty strange, and therefore infuriating, bug concerning Maven. I've been using it for a year or two now and have only gotten a single build error before, when I first started using it. Suddenly, this problem has shown itself.
The red arrows indicate the lines that are causing the build failure.
This is a screenshot of the Maven logs that are causing the issue.
Well, according to the Bukkit API docs (note that the official docs seem to be down, thus third party), the class InventoryClickEvent has no method getClickedInventory().
This fact definitely explains your compilation error. The error comes from your Java compiler, Maven has nothing to do with it.
We recently migrated from Cognos 10.1.1 to Cognos 10.2.1.1 ( 10.2.1 plus Fix pack1) . Some of our existing reports fail validation now.
From the cogserver.log file , it looks like the BIBUS Process is Crashing on validating the report.
We are working with IBM tech support via a PMR .
Wanted to try if someone here knows if it is possible to Validate a report step by step so that I can get some information or some logs on what element in our report is exactly causing the issue? i.e. Is it possible to do the report validation in a debug mode somehow?
Oh, what a wonderful feature that would be, but to my knowledge nothing like that exists at all. You could try setting the logging on your dispatcher(s) to the maximum to see if you can get any more informative errors.
I would start by trying to view the tabular data for each query individually. If you can identify which query (or queries) are causing your problems, then you can just remove items from the query until it doesn't fail, at which point you should have a pretty good idea of what the source of the problem is.
If that doesn't work, I would just start ripping major chunks of the report out and seeing you can get it to run. For example, if you have a report with 4 charts, delete half of them and try your report. Revert back to the original report, and delete the other half. Get it to work, and then start removing stuff from the half that fails until you can narrow it down to your problem.
It's kind of slow, but these approaches have always worked for me.
On a side note, we're about to make the same upgrade, I'd be interested in hearing what you learn.
EDIT:
Oh, forgot. Make sure you disable DQM and test your reports that way, if you haven't.
Unfortunately, there's no way to debug step by step. Finally got the Core dumps for the crashes, sent them over to IBM Folks ; and they identified it as a known bug in 10.2.1.1. So now we are at 10.2.1.2 (applied Fix pack 2) which solves the issue.
I am reading through Informix 4GL By Example. Ex4 is giving a segmentation fault so I am attempting to use the debugger to find out where the program is failing, but the debugger is not working.
From within r4gl, I can compile forms and modules. But when I debug it shows a blank screen with
"Press Return to continue".
From the command line fgldb returns the following error:
fgldb: symbol lookup error: fgldb: undefined symbol: kw__numkws
DB is up and running, I can isql in and run queries.
System details:
OpenSuSE 12.1 32 bit
Informix RDS 7.50 UC6
Informix SQL DEV 7.50 UC6
Informix Growth Edition 11.70 UC5
Informix Interactive Debugger 7.50 UC6
I have searched the net, but have not found anything helpful. Any idea what's wrong?
UPDATE 1:
Thank you again for the assistance. I will be trying to install in a seperate directory and let you know. This is probably blonde but how do I install in a different directory. If I attempt to I get errors:
"INFORMIXDIR and working directory do not match."
"INFORMIXDIR = /usr/informix"
"Current working directory = /usr/informix/i4gl"
Can I edit $INFORMIXDIR to match where I want to install?
Many thanks,
Neill
UPDATE 2:
OK, so I got them both installed in /usr/informix/i4gl.
Set variables to point to that directory, not sure exactly which ones need to though because I still receive errors.
fgldb: -16326: Cannot open file 'fgldb.iem'
The /usr/informix/i4gl does contain a directory msg/en_us/0333, but that file does not exist there, while /usr/informix/msg/en_us/0333 does include the fgldb.iem file.
isql -> Query Language: Says SELECT DATABASE, but none or shown for me to select.
Kind regards
Neill
UPDATE 3:
OK, my blonde momnets are getting crazy now, but after installing into /usr/informix/i4gl, I never changed back the $INFORMIXDIR variable. I did this and then stopped and started the DB.
Now when trying to compile the demo f_custkey.per (using stores_demo db as before) form, I get errors -329 and -2810, which are to do with the database not found.
I am not sure if this is what you were talking about in your last statement. I am unsure if splitting these two into seperate directories has solved my debugger issue because now I can't compile anything, but I sense I am getting close.
Kind regards,
Neill
UPDATE 4 - Final!
OK, so it is working now.
Ran the dbaccessdemo7 command again to recreate the database and all is well in the land of nod.
Compiling and debugging ex4 now works.
Thank you so much for all the information. Learning as I go.
Kind regards
Neill
The kw_numkws issue is fixed post 7.50.UC6. So the next available fixpack will have the fix.
In the interim, IBM Technical Support has posted a "Tech Alert" advising customers to install I4GL (and ISQL) in a separate directory - option #2 suggested by Jonathan Leffler above.
The core dump/crash that you're hitting is an unfortunate bug that we found out about earlier this week. The ESQL/C code is fixed (as of today), but the fixed releases are not yet available, and won't be for a while (read 'until after Thanksgiving at the earliest'). The I4GL and ISQL code still has to be fixed (some separate, but closely related problems).
What's happened is that a structure changed size in the CSDK. I4GL will be compiling the code with the one size and the CSDK libraries are expecting another size; the difference is about 4 bytes.
This leads to hard to track memory overwriting.
The kw__numkws issue is an older problem that I thought was fixed in 7.50.UC6. I'll have to check whether that release did get the fix, and if so, how you are seeing that error still.
There are a couple of short-term options that should get you going until a fixed ensemble is available:
Reinstall I4GL (and ISQL) in the server directory. I've not proved that this will work. The concept is to make sure I4GL is using the CSDK libraries it was built with, rather than the updated 3.70.xC6 version.
Reinstall I4GL (and ISQL) in a separate directory (/opt/IBM/i4gl, perhaps). Have a suitable sqlhosts file in this directory; it might be a symlink to the one in the IDS directory. Point the I4GL programs at this alternative directory, setting LD_LIBRARY_PATH appropriately.
Option 2 ensures that I4GL is using the 'correct' CSDK. Option 1 may achieve the same result, but I'm not ready to guarantee it. Consequently, I suggest option 2.
If your I4GL code needs to run DB-Access or other programs found in the server $INFORMIXDIR, there are ways to deal with that — indicate in a comment and I'll explain, but I'd rather not confound you if there's no need. (It's not dreadfully hard, but it isn't completely trivial either.)
Option 3. is to discover what CSDK was used to create the 4GL tools and install THAT instead of the current one. In the case of 4GL 7.50FC6 it CSDK 3.70FC4.
I had problems splitting up the engine and the tools. This appears to work, so far.