On Tue, Jul 9, 2024 at 1:16 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote:
On Sat, Jul 06, 2024 at 02:05:37AM +0200, Siteshwar Vashisht wrote:
> Hello,
>
> I am writing this message to get feedback from the community on possibly
> new defects identified by static analyzers in Critical Path Packages that
> have changed in Fedora 41. For context, please see my previous email[1].
>
> TLDR: This report[2] contains 73976 identified defects. Please review the
> report and provide feedback.
Calling these "Identified defects" is way too strong & a misleading
portrayal of package quality IMHO.
These are identified code locations which may or may not be defects.
We've no idea what the actual defect level is, amongst the false
positives, unless humans analyse each report.
>
> A mass scan was performed this week on the packages that have changed in
> Fedora 41. This report[2] contains all the new defects that have been
> identified in the packages listed in Critical Path Packages. Please review
> the report and fix or report any defects to upstream that may be real bugs.
> Not all defects reported by OpenScanHub may be actual bugs, so please
> verify reported defects before investing time into fixing or reporting
> them. We hope this is helpful for the packages you maintain and for the
> upstream projects. Questions can be asked on the OpenScanHub mailing
> list[3]. If you want to see the full logs of the scans, they are available
> on the tasks[4] page. User documentation for performing a scan is available
> on the Fedora wiki[5].
>
> Please remember this is currently an early production stage for OpenScanHub
> scanning. Constructive feedback is appreciated. Thank you!
For packages I'm involved in (QEMU, libvirt), there are a huge number of
reported "flaws". The false positive error reports level is way too high
for me to spend time looking at these reports in any detail though.
The biggest problem is that the clang 'warning[unix.Malloc]' check doesn't
understand that __attribute__((cleanup)) functions (via the glib g_autofree
/ g_autoptr macros) will free memory. On libvirt this accounts for 35% of
all warnings list, and QEMU it accounts for about 20% of warnings. There
are probably some real memory leaks there, but it is impractical to search
for them amongst the noise.
Another 30% are "DeadStore" warnings which, while correct, are also harmless
and not something we intend to fix since this is generated code & making the
generator more complex is not desired.
I request somebody from the tools team to comment on these concerns. We only report the defects identified by gcc, clang etc.
Ignoring those and picking a random sample of what's left, I still find
that everything I look at is a false positive. Again I'm sure there are
probably some real bugs hiding in there, but it is impractical to find
them :-(
These high false positive levels are what's stopping us from enabling
the very same GCC and CLang analysis features in our upstream CI.
The issue of false positives has come up multiple times and I have opened an upstream issue[1] to discuss a solution.
There are likely packages in Fedora which won't trigger such high false
positives rates, making these downstream CI tests useful. I would be
wary of reading too much into the overall global Fedora "flaw" counts
though.
You are right that the usefulness of this service may vary with each package, especially until we find a way to mark false positives.
Thank you for the detailed feedback!
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
