{"id":343,"date":"2014-10-18T12:12:47","date_gmt":"2014-10-18T12:12:47","guid":{"rendered":"http:\/\/blogs.gentoo.org\/lu_zero\/?p=343"},"modified":"2015-08-29T09:02:59","modified_gmt":"2015-08-29T09:02:59","slug":"fix-all-the-bugs","status":"publish","type":"post","link":"https:\/\/blogs.gentoo.org\/lu_zero\/2014\/10\/18\/fix-all-the-bugs\/","title":{"rendered":"Fix ALL the BUGS!"},"content":{"rendered":"

Vittorio<\/a> started (with some help from me) to fix all the issues pointed by Coverity<\/a>.<\/p>\n

Static analysis<\/h2>\n

Coverity (and scan-build<\/a>) are quite useful to spot mistakes even if their false-positive ratio tend to be quite high. Even the false-positives<\/strong> are usually interesting since the spot code unnecessarily convoluted. The code should be as simple<\/strong> as possible but not simpler<\/strong>.<\/p>\n

The basic idea behind those tools is to try to follow the code-paths<\/strong> while compiling them and spot what could go wrong (e.g. you are feeding a NULL to a function that would deference it).<\/p>\n

The problems with this approach are usually two: false positive due to the limited scope of the analyzer and false negatives due shadowing.<\/p>\n

False Positives<\/h3>\n

Coverity might assume certain inputs are valid even if they are made impossible by some initial checks up in the codeflow.<\/p>\n

In those case you should<\/strong> spend enough time to make sure Coverity is not right and those faulty inputs aren’t slipping somewhere. NEVER<\/strong> try to just add some checks to the code pointed as first move, you might either hide issues (e.g. if Coverity complains about uninitialized variable do not<\/strong> just initialize it to nothing, check why it happens and if the logic behind is wrong).<\/p>\n

\nIf Coverity is confused<\/b>, your compiler is confused as well and will produce suboptimal executables.<\/br> Properly fixing those issues can result in useful speedups. Simpler<\/b> code is usually faster.\n<\/div>\n

Ever increasing issue count<\/h3>\n

While fixing issues using those tools you might notice to your surprise that every time you fix something, something new appears out of thin air.<\/p>\n

This is not magic but simply that the static analyzers usually keep some limit on how deep<\/strong> they go depending on the issues already present and how much time<\/strong> had been spent already.<\/p>\n

That surprise had been fun since apparently some of the time limit is per compilation unit so splitting large files in smaller chunks gets us more results (while speeding up the building process thanks to better parallelism).<\/p>\n

Usually fixing some high-impact<\/strong> issue gets us 3 or 5 new small impact issues.<\/p>\n

I like solving puzzles so I do not mind having more fun, sadly I did not have much spare time to play this game lately.<\/p>\n

Merge ALL the FIXES<\/h2>\n
\nFixing properly all the issues is a lofty goal and as usual having a patch is just 1\/2 of the work. Usually two set of eyes work better than one and an additional brain with different expertise can prevent a good chunk of mistakes. The review process<\/b> is the other, sometimes neglected, half of solving issues.\n<\/div>\n

So far about 100+<\/strong> patches got piled up over the past weeks and now they are sent in small batches to ease the work of review. (I have something<\/a> brewing to make reviewing simpler, as you might know)<\/p>\n

During the review what probably about 1\/10 of the patches will be rejected and the relative coverity report updated with enough information to explain why it is a false positive or the dangerous or strange behaviour pointed is intentional.<\/p>\n

\nThe next point release for our 4 maintained major releases: 0.8<\/a>, 9<\/a>, 10<\/a> and 11<\/a>. Many thanks to the volunteers that spend their free time keeping all the branches up to date!\n<\/div>\n","protected":false},"excerpt":{"rendered":"

Vittorio started (with some help from me) to fix all the issues pointed by Coverity. Static analysis Coverity (and scan-build) are quite useful to spot mistakes even if their false-positive ratio tend to be quite high. Even the false-positives are usually interesting since the spot code unnecessarily convoluted. The code should be as simple as … Continue reading Fix ALL the BUGS!<\/span><\/a><\/p>\n","protected":false},"author":10,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spay_email":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true},"categories":[14,6],"tags":[22],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p1aGWH-5x","_links":{"self":[{"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/posts\/343"}],"collection":[{"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/users\/10"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/comments?post=343"}],"version-history":[{"count":5,"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/posts\/343\/revisions"}],"predecessor-version":[{"id":358,"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/posts\/343\/revisions\/358"}],"wp:attachment":[{"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/media?parent=343"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/categories?post=343"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/lu_zero\/wp-json\/wp\/v2\/tags?post=343"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}