Coverity builds
#1
Brick 
Hi,

I was wondering if there are any plans to do more regular Coverity builds? As I believe the value of static analysis is in the regularity of it saying stuff has changed/broken.

The current xbmc project is on:
https://scan.coverity.com/projects/248
and last had a build 4 months ago.

Looking over the current list of coverity issues there are a fair number that wouldn't be hard to fix (uninitialized variables in class constructors seem to be the biggest offender), but without fresh scans it'd be hard to confirm that they get fixed.

I believe it was also help raise the "quality" as Coverity can help avoid silly mistakes creeping in.

From what I can tell coverity offer the option to feed scan data from various sources, or run actual builds. I suspect that Jenkins could do coverity builds, nightly or weekly, and push the results. The advantage with Jenkins doing it would probably be platform coverage, as it would then do windows and linux.

Another option maybe to use travis_ci to do a coverity build:
https://scan.coverity.com/travis_ci

I would offer to assist, but it needs access to various things which I don't have (and don't expect to have, as I'm new around here Smile )

I could cheat the system, and add my github fork of xbmc to it, but that would seem to defeat the purpose, although perhaps it would let me generate fixes and confirm that the fix resolves the issue.

If anyone was wondering what some of the issues are it finds are, I fixed a few here (null de-ref checks missing/wrong place, resource leak and in correct exception thrown):
https://github.com/xbmc/xbmc/pull/4431

It's also pointed out things that are just strange (which I will raise as a bug), eg this loop:
https://github.com/xbmc/xbmc/blob/master...o.cpp#L469

It leaks resource, as dsub is not freed, or referenced, I suspect it should be adding the dsub to the stream.
And the i++ is unreachable, because the return true is inside the loop.

I would take a stab at fixing it, but I know nothing about the subtitles code and what the desired behaviour is.

Thoughts,
Chris
Reply
#2
(2014-03-15, 14:31)cg110 Wrote: It's also pointed out things that are just strange (which I will raise as a bug), eg this loop:
https://github.com/xbmc/xbmc/blob/master...o.cpp#L469

It leaks resource, as dsub is not freed, or referenced, I suspect it should be adding the dsub to the stream.
And the i++ is unreachable, because the return true is inside the loop.

I would take a stab at fixing it, but I know nothing about the subtitles code and what the desired behaviour is.

It's hard to imagine what that code is meant to be. I'm guessing a copy/paste or bad merge conflict has produced that. It appeared here:
https://github.com/xbmc/xbmc/commit/d430...b3ee01965d

Perhaps ace20022 can suggest what was intended.
Reply
#3
Thanks for the heads up! Will fix it, I have no idea how this could make it in..
Reply
#4
Hi,

I've noticed that something odd has been happening with the builds that have recently been submitted to coverity, as I find it hard to believe that 1,000+ defects have been fixed.

I'm wondering if someone is making builds in an odd way, as not only did 1,000+ defects disappear, some of the new ones are very odd, eg:

>>> CID 1197656: Logically dead code (DEADCODE)
>>> Execution cannot reach the expression "0" inside this statement: "(0 && ((__s1_len = __builti...".
62 if (!strcmp (cpuid, "AuthenticAMD")) {

Suggests something very odd happening with the compilation.

I'm wondering if ccache is in use with those builds, as that hides the compilation from coverity. Or perhaps it's the version of gcc.

I was doing builds on ubuntu 12.04, perhaps the builds are on something else, or not doing a full clean before building. I've a script I was using to do the builds at home, so that I made sure everything was clean and ccache wasn't used. I can upload the script when I get home.

I'm hoping we can understand what the difference is between the builds I was doing and the recently uploaded builds, so that we don't seem to keep bouncing up and down on defect counts.

Thanks,
Chris
Reply
#5
14.04
full clean
could that last build had some issue with the rebranding PR merged.
Read/follow the forum rules.
For troubleshooting and bug reporting, read this first
Interested in seeing some YouTube videos about Kodi? Go here and subscribe
Reply
#6
Could be, I was just surprised to see such a drop in the defect count. But also some strange new defects (especially on code that's not changed for some time (not to say there aren't defects there, as new checkers get added))

I guess 14.04 is a new gcc version, but can't see how it ends up parsing the strcmp to a (0 && ...) clause, unless it's some kind of weird preprocessing that's happening.

I'll try and find time to dig into the full details tonight.
Reply
#7
Martjin, are you sure no ccache is installed? Its used by default.
Reply
#8
will check when i have my dev pc online
Read/follow the forum rules.
For troubleshooting and bug reporting, read this first
Interested in seeing some YouTube videos about Kodi? Go here and subscribe
Reply
#9
uploaded new build to coverity. defects should be back to normal.
Read/follow the forum rules.
For troubleshooting and bug reporting, read this first
Interested in seeing some YouTube videos about Kodi? Go here and subscribe
Reply

Logout Mark Read Team Forum Stats Members Help
Coverity builds0