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.
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!
[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... [2] https://svashisht.fedorapeople.org/f41-03-Jul-2024/ [3] https://lists.fedoraproject.org/archives/list/openscanhub@lists.fedoraprojec... [4] https://openscanhub.fedoraproject.org/task/ [5] https://fedoraproject.org/wiki/OpenScanHub
On Sat, Jul 6, 2024 at 2:05 AM Siteshwar Vashisht svashisht@redhat.com 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].
There were a large number of false positives reported due to cppcheck warning about limiting analysis of branches.
I have added the --check-level=exhaustive option to cppcheck. Here is an example report:
Without --check-level=exhaustive:
https://openscanhub.fedoraproject.org/task/242/log/units-2.22-6.fc39/scan-re...
With --check-level=exhaustive:
https://openscanhub.fedoraproject.org/task/2029/log/units-2.22-6.fc39/scan-r...
So this issue should not happen in the future.
TLDR: This report[2] contains 73976 identified defects. Please review the report and provide feedback.
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!
[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... [2] https://svashisht.fedorapeople.org/f41-03-Jul-2024/ [3] https://lists.fedoraproject.org/archives/list/openscanhub@lists.fedoraprojec... [4] https://openscanhub.fedoraproject.org/task/ [5] https://fedoraproject.org/wiki/OpenScanHub
-- Siteshwar Vashisht
On Tuesday, July 9, 2024 12:45:18 PM CEST Siteshwar Vashisht wrote:
On Sat, Jul 6, 2024 at 2:05 AM Siteshwar Vashisht svashisht@redhat.com 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].
There were a large number of false positives reported due to cppcheck warning about limiting analysis of branches.
I have added the --check-level=exhaustive option to cppcheck. Here is an example report:
Without --check-level=exhaustive:
https://openscanhub.fedoraproject.org/task/242/log/units-2.22-6.fc39/scan-re...
As this is a problem with the analysis rather than a problem with the source code being analyzed, I propose to filter these warnings out in the csmock plug-in, as we do for cppcheckError, syntaxError, and the like: https://github.com/csutils/csmock/blob/b3a2279468e7440553d0757b0d93c58791e13...
With --check-level=exhaustive:
https://openscanhub.fedoraproject.org/task/2029/log/units-2.22-6.fc39/scan-r...
So this issue should not happen in the future.
The downside of using `--check-level=exhaustive` is that Cppcheck might be killed by a timeout (set to 30s by default) before reporting other useful bugs.
Kamil
On Tue, Jul 16, 2024 at 4:55 PM Kamil Dudka kdudka@redhat.com wrote:
On Tuesday, July 9, 2024 12:45:18 PM CEST Siteshwar Vashisht wrote:
On Sat, Jul 6, 2024 at 2:05 AM Siteshwar Vashisht svashisht@redhat.com 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].
There were a large number of false positives reported due to cppcheck warning about limiting analysis of branches.
I have added the --check-level=exhaustive option to cppcheck. Here is an example report:
Without --check-level=exhaustive:
https://openscanhub.fedoraproject.org/task/242/log/units-2.22-6.fc39/scan-re...
As this is a problem with the analysis rather than a problem with the source code being analyzed, I propose to filter these warnings out in the csmock plug-in, as we do for cppcheckError, syntaxError, and the like: https://github.com/csutils/csmock/blob/b3a2279468e7440553d0757b0d93c58791e13...
It should be fixed by the next release of csmock[1].
With --check-level=exhaustive:
https://openscanhub.fedoraproject.org/task/2029/log/units-2.22-6.fc39/scan-r...
So this issue should not happen in the future.
The downside of using `--check-level=exhaustive` is that Cppcheck might be killed by a timeout (set to 30s by default) before reporting other useful bugs.
Kamil
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.
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.
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.
With regards, Daniel
On Tue, Jul 9, 2024 at 1:16 PM Daniel P. Berrangé berrange@redhat.com 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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Tue, 2024-07-09 at 13:37 +0200, Siteshwar Vashisht wrote:
On Tue, Jul 9, 2024 at 1:16 PM Daniel P. Berrangé berrange@redhat.com 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.
I'm on RH's tools team (I work on upstream GCC), and I'll comment a little on the specifics of the above in a separate mail.
That said, I think there are two high-level issues here, which someone (probably on the openscanhub team???) needs to be responsible for:
(a) improving the readability of these generated reports so that if someone clicks on a report it gives them enough information to assess it, otherwise the report is effectively "noise".
(b) "curating" the warnings: doing an initial pass through the taxonomy of warnings, and prioritizing some subset that seems worth the attention of the package maintainers, and focusing on that (and gradually tuning/expanding this).
Regarding (a) I've spent a *lot* of work in upstream GCC to try to make -fanalyzer's reports readable e.g. showing predicted execution paths that trigger a problem, both in terms of capturing the data, and visualizing it. However, looking at e.g. https://openscanhub.fedoraproject.org/task/242/log/units-2.22-6.fc39/scan-re... these aren't visible in the reports you linked to, simply the site of the final problem. This isn't helpful, and is frustrating, given that GCC *is* emitting the pertinent information, but it's being lost somewhere in openscanhub's reporting pipeline. FWIW GCC 13 onwards can emit its reports in SARIF format, and other recent analyzer tools can do so too (see e.g. https://github.com/oasis-tcs/sarif-spec/wiki/Known- Producers-and-Consumers#known-producers-of-sarif ). For a future GCC (15?) I've been experimenting with exposing GCC's path-visualization code via a new libdiagnostics.so shared library (https://gcc.gnu.org/wiki/libdiagnostics), perhaps with a precanned way to "replay" .sarif files, which should make it fairly easy to generate nice HTML from SARIF showing more context for a warning. Siteshwar, let me know if you want to work with me on getting that working in your pipeline (if so, I can raise the priority of it in my own task list).
I can look at specific bugs in GCC's -fanalyzer if there are patterns of false positives (ideally please file them in upstream gcc bugzilla with simple reproducers), or help with specific examples, but right now without (a) to me the output is unusable noise, sorry.
Siteshwar, I'm hoping that you or somoneone else associated with openscanhub will volunteer to do (a) and/or (b), or know people who will; I think these are the two next steps that openscanhub as a project should be taking.
[...snip...]
Hope this is constructive Dave
On Tue, Jul 9, 2024 at 10:10 PM David Malcolm dmalcolm@redhat.com wrote:
On Tue, 2024-07-09 at 13:37 +0200, Siteshwar Vashisht wrote:
On Tue, Jul 9, 2024 at 1:16 PM Daniel P. Berrangé berrange@redhat.com 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.
I'm on RH's tools team (I work on upstream GCC), and I'll comment a little on the specifics of the above in a separate mail.
That said, I think there are two high-level issues here, which someone (probably on the openscanhub team???) needs to be responsible for:
(a) improving the readability of these generated reports so that if someone clicks on a report it gives them enough information to assess it, otherwise the report is effectively "noise".
(b) "curating" the warnings: doing an initial pass through the taxonomy of warnings, and prioritizing some subset that seems worth the attention of the package maintainers, and focusing on that (and gradually tuning/expanding this).
Good point. We need to come up with some new (or reuse existing) tooling to mark important warnings.
Regarding (a) I've spent a *lot* of work in upstream GCC to try to make -fanalyzer's reports readable e.g. showing predicted execution paths that trigger a problem, both in terms of capturing the data, and visualizing it. However, looking at e.g.
https://openscanhub.fedoraproject.org/task/242/log/units-2.22-6.fc39/scan-re... these aren't visible in the reports you linked to, simply the site of the final problem. This isn't helpful, and is frustrating, given that GCC *is* emitting the pertinent information, but it'
This has been discussed in the past, and you can use below command to see more verbose output:
curl -s " https://openscanhub.fedoraproject.org/task/242/log/units-2.22-6.fc39/scan-re..." | csgrep
It is actually documented in the wiki[1].
s being lost somewhere in openscanhub's reporting pipeline. FWIW GCC 13 onwards can emit its reports in SARIF format, and other recent analyzer tools can do so too (see e.g. https://github.com/oasis-tcs/sarif-spec/wiki/Known- Producers-and-Consumers#known-producers-of-sarif https://github.com/oasis-tcs/sarif-spec/wiki/Known-Producers-and-Consumers#known-producers-of-sarif ). For a future GCC (15?) I've been experimenting with exposing GCC's path-visualization code via a new libdiagnostics.so shared library (https://gcc.gnu.org/wiki/libdiagnostics), perhaps with a precanned way to "replay" .sarif files, which should make it fairly easy to generate nice HTML from SARIF showing more context for a warning. Siteshwar, let me know if you want to work with me on getting that working in your pipeline (if so, I can raise the priority of it in my own task list).
Either me or somebody from the OpenScanHub team should be able to coordinate with you about it.
I can look at specific bugs in GCC's -fanalyzer if there are patterns of false positives (ideally please file them in upstream gcc bugzilla with simple reproducers), or help with specific examples, but right now without (a) to me the output is unusable noise, sorry.
Siteshwar, I'm hoping that you or somoneone else associated with openscanhub will volunteer to do (a) and/or (b), or know people who will; I think these are the two next steps that openscanhub as a project should be taking.
Yes, we should be able to coordinate on this. Kamil Dudka, the lead of OpenScanHub, is currently on PTO. I would get back to you on this when he is back next week.
[...snip...]
Hope this is constructive
Thanks for the feedback!
Dave
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Wed, Jul 10, 2024 at 11:10:34AM +0200, Siteshwar Vashisht wrote:
On Tue, Jul 9, 2024 at 10:10 PM David Malcolm dmalcolm@redhat.com wrote:
On Tue, 2024-07-09 at 13:37 +0200, Siteshwar Vashisht wrote:
On Tue, Jul 9, 2024 at 1:16 PM Daniel P. Berrangé berrange@redhat.com 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.
I'm on RH's tools team (I work on upstream GCC), and I'll comment a little on the specifics of the above in a separate mail.
That said, I think there are two high-level issues here, which someone (probably on the openscanhub team???) needs to be responsible for:
(a) improving the readability of these generated reports so that if someone clicks on a report it gives them enough information to assess it, otherwise the report is effectively "noise".
(b) "curating" the warnings: doing an initial pass through the taxonomy of warnings, and prioritizing some subset that seems worth the attention of the package maintainers, and focusing on that (and gradually tuning/expanding this).
Good point. We need to come up with some new (or reuse existing) tooling to mark important warnings.
Regarding (a) I've spent a *lot* of work in upstream GCC to try to make -fanalyzer's reports readable e.g. showing predicted execution paths that trigger a problem, both in terms of capturing the data, and visualizing it. However, looking at e.g.
https://openscanhub.fedoraproject.org/task/242/log/units-2.22-6.fc39/scan-re... these aren't visible in the reports you linked to, simply the site of the final problem. This isn't helpful, and is frustrating, given that GCC *is* emitting the pertinent information, but it'
This has been discussed in the past, and you can use below command to see more verbose output:
curl -s " https://openscanhub.fedoraproject.org/task/242/log/units-2.22-6.fc39/scan-re..." | csgrep
It is actually documented in the wiki[1].
Having ability to process data from the CLI is great, but I'd still encourage you to look at making the HTML reports more usable.
One improvement that is fairly easy is to present a menu at the top of the page listing all checkers, and all check types within that checker, and allow each checker overall, individual checks, to be toggled visible.
eg this semi-working crude mockup :
https://berrange.fedorapeople.org/scan.html
With regards, Daniel
On Wed, Jul 10, 2024 at 12:21 PM Daniel P. Berrangé berrange@redhat.com wrote:
On Wed, Jul 10, 2024 at 11:10:34AM +0200, Siteshwar Vashisht wrote:
On Tue, Jul 9, 2024 at 10:10 PM David Malcolm dmalcolm@redhat.com
wrote:
On Tue, 2024-07-09 at 13:37 +0200, Siteshwar Vashisht wrote:
On Tue, Jul 9, 2024 at 1:16 PM Daniel P. Berrangé berrange@redhat.com 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.
I'm on RH's tools team (I work on upstream GCC), and I'll comment a little on the specifics of the above in a separate mail.
That said, I think there are two high-level issues here, which someone (probably on the openscanhub team???) needs to be responsible for:
(a) improving the readability of these generated reports so that if someone clicks on a report it gives them enough information to assess it, otherwise the report is effectively "noise".
(b) "curating" the warnings: doing an initial pass through the taxonomy of warnings, and prioritizing some subset that seems worth the attention of the package maintainers, and focusing on that (and gradually tuning/expanding this).
Good point. We need to come up with some new (or reuse existing) tooling
to
mark important warnings.
Regarding (a) I've spent a *lot* of work in upstream GCC to try to make -fanalyzer's reports readable e.g. showing predicted execution paths that trigger a problem, both in terms of capturing the data, and visualizing it. However, looking at e.g.
https://openscanhub.fedoraproject.org/task/242/log/units-2.22-6.fc39/scan-re...
these aren't visible in the reports you linked to, simply the site of the final problem. This isn't helpful, and is frustrating, given that GCC *is* emitting the pertinent information, but it'
This has been discussed in the past, and you can use below command to see more verbose output:
curl -s "
https://openscanhub.fedoraproject.org/task/242/log/units-2.22-6.fc39/scan-re... "
| csgrep
It is actually documented in the wiki[1].
Having ability to process data from the CLI is great, but I'd still encourage you to look at making the HTML reports more usable.
One improvement that is fairly easy is to present a menu at the top of the page listing all checkers, and all check types within that checker, and allow each checker overall, individual checks, to be toggled visible.
eg this semi-working crude mockup :
Thanks for sharing the prototype! I have been using some internal scripts that were used to create reports for RHEL, but we can develop something more user friendly for the community for future mass scans.
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 :|
On Wed, Jul 10, 2024 at 12:29 PM Siteshwar Vashisht svashisht@redhat.com wrote:
On Wed, Jul 10, 2024 at 12:21 PM Daniel P. Berrangé berrange@redhat.com wrote:
On Wed, Jul 10, 2024 at 11:10:34AM +0200, Siteshwar Vashisht wrote:
On Tue, Jul 9, 2024 at 10:10 PM David Malcolm dmalcolm@redhat.com wrote:
On Tue, 2024-07-09 at 13:37 +0200, Siteshwar Vashisht wrote:
On Tue, Jul 9, 2024 at 1:16 PM Daniel P. Berrangé berrange@redhat.com 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.
I'm on RH's tools team (I work on upstream GCC), and I'll comment a little on the specifics of the above in a separate mail.
That said, I think there are two high-level issues here, which someone (probably on the openscanhub team???) needs to be responsible for:
(a) improving the readability of these generated reports so that if someone clicks on a report it gives them enough information to assess it, otherwise the report is effectively "noise".
(b) "curating" the warnings: doing an initial pass through the taxonomy of warnings, and prioritizing some subset that seems worth the attention of the package maintainers, and focusing on that (and gradually tuning/expanding this).
Good point. We need to come up with some new (or reuse existing) tooling to mark important warnings.
Regarding (a) I've spent a *lot* of work in upstream GCC to try to make -fanalyzer's reports readable e.g. showing predicted execution paths that trigger a problem, both in terms of capturing the data, and visualizing it. However, looking at e.g.
https://openscanhub.fedoraproject.org/task/242/log/units-2.22-6.fc39/scan-re... these aren't visible in the reports you linked to, simply the site of the final problem. This isn't helpful, and is frustrating, given that GCC *is* emitting the pertinent information, but it'
This has been discussed in the past, and you can use below command to see more verbose output:
curl -s " https://openscanhub.fedoraproject.org/task/242/log/units-2.22-6.fc39/scan-re..." | csgrep
It is actually documented in the wiki[1].
Having ability to process data from the CLI is great, but I'd still encourage you to look at making the HTML reports more usable.
One improvement that is fairly easy is to present a menu at the top of the page listing all checkers, and all check types within that checker, and allow each checker overall, individual checks, to be toggled visible.
eg this semi-working crude mockup :
Thanks for sharing the prototype! I have been using some internal scripts that were used to create reports for RHEL, but we can develop something more user friendly for the community for future mass scans.
We have started discussing this issue on the csmock[1] GitHub repository. Please leave any comments there. Thanks!
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 :|
On Tue, 2024-07-09 at 13:37 +0200, Siteshwar Vashisht wrote:
On Tue, Jul 9, 2024 at 1:16 PM Daniel P. Berrangé berrange@redhat.com 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.
I don't know about the clang analyzer, but FWIW GCC's -fanalyzer has code to handle __attribute__((cleanup)) and thus shouldn't have this issue (see e.g. upstream bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108733 ). But there's certainly other bugs in -fanalyzer that it could be running into.
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.
Which analyzer is emitting that?
[...snip...]
Dave
On Tue, Jul 09, 2024 at 04:03:10PM -0400, David Malcolm wrote:
On Tue, 2024-07-09 at 13:37 +0200, Siteshwar Vashisht wrote:
On Tue, Jul 9, 2024 at 1:16 PM Daniel P. Berrangé berrange@redhat.com wrote:
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.
I don't know about the clang analyzer, but FWIW GCC's -fanalyzer has code to handle __attribute__((cleanup)) and thus shouldn't have this issue (see e.g. upstream bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108733 ). But there's certainly other bugs in -fanalyzer that it could be running into.
Yeah, in the openscanhub reports, the bogus memory leaks appear to be from CLang rather than GCC.
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.
Which analyzer is emitting that?
This was again CLang.
With regards, Daniel
On Wed, Jul 10, 2024 at 1:30 AM Daniel P. Berrangé berrange@redhat.com wrote:
On Tue, Jul 09, 2024 at 04:03:10PM -0400, David Malcolm wrote:
On Tue, 2024-07-09 at 13:37 +0200, Siteshwar Vashisht wrote:
On Tue, Jul 9, 2024 at 1:16 PM Daniel P. Berrangé berrange@redhat.com wrote:
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.
I don't know about the clang analyzer, but FWIW GCC's -fanalyzer has code to handle __attribute__((cleanup)) and thus shouldn't have this issue (see e.g. upstream bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108733 ). But there's certainly other bugs in -fanalyzer that it could be running into.
Yeah, in the openscanhub reports, the bogus memory leaks appear to be from CLang rather than GCC.
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.
Which analyzer is emitting that?
This was again CLang.
I plan to disable Clang during the next mass scan to decrease the number of false positives in the report. Thanks!
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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Wed, Jul 17, 2024 at 2:32 PM Siteshwar Vashisht svashisht@redhat.com wrote:
On Wed, Jul 10, 2024 at 1:30 AM Daniel P. Berrangé berrange@redhat.com wrote:
On Tue, Jul 09, 2024 at 04:03:10PM -0400, David Malcolm wrote:
On Tue, 2024-07-09 at 13:37 +0200, Siteshwar Vashisht wrote:
On Tue, Jul 9, 2024 at 1:16 PM Daniel P. Berrangé berrange@redhat.com wrote:
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.
I don't know about the clang analyzer, but FWIW GCC's -fanalyzer has code to handle __attribute__((cleanup)) and thus shouldn't have this issue (see e.g. upstream bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108733 ). But there's certainly other bugs in -fanalyzer that it could be running into.
Yeah, in the openscanhub reports, the bogus memory leaks appear to be from CLang rather than GCC.
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.
Which analyzer is emitting that?
This was again CLang.
I plan to disable Clang during the next mass scan to decrease the number of false positives in the report. Thanks!
I have already disabled it, so you should see less noise in the reports. Thanks for the 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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Tuesday, July 9, 2024 1:16:23 PM CEST Daniel P. Berrangé 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.
This is a bug of Clang Analyzer that was reported upstream in 2009: - https://bugs.llvm.org/show_bug.cgi?id=3888 - https://github.com/llvm/llvm-project/issues/4260
Kamil
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.
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.
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.
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 :|
On 7/5/24 17:05, 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.
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!
The scan for LLVM reported 0 issues, which seems unlikely. Is it possible the scan timed out? We run the clang static analyzer upstream and it does report issues: https://github.com/llvm/llvm-project/actions/runs/9866302541/job/27244829483
-Tom
[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OMKLJFW4VC242QSA7R4KMGI6IGBT3YLM/ [2] https://svashisht.fedorapeople.org/f41-03-Jul-2024/ https://svashisht.fedorapeople.org/f41-03-Jul-2024/ [3] https://lists.fedoraproject.org/archives/list/openscanhub@lists.fedoraprojec... https://lists.fedoraproject.org/archives/list/openscanhub@lists.fedoraproject.org/ [4] https://openscanhub.fedoraproject.org/task/ https://openscanhub.fedoraproject.org/task/ [5] https://fedoraproject.org/wiki/OpenScanHub https://fedoraproject.org/wiki/OpenScanHub
-- Siteshwar Vashisht
On Wed, Jul 10, 2024 at 7:15 AM Tom Stellard tstellar@redhat.com wrote:
On 7/5/24 17:05, 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.
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!
The scan for LLVM reported 0 issues, which seems unlikely. Is it possible the scan timed out? We run the clang static analyzer upstream and it does report issues:
https://github.com/llvm/llvm-project/actions/runs/9866302541/job/27244829483
The scan seems to be successful[1], we probably missed some flags that you may be using upstream.
-Tom
[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... < https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
https://svashisht.fedorapeople.org/f41-03-Jul-2024/%3E
[3]
https://lists.fedoraproject.org/archives/list/openscanhub@lists.fedoraprojec... < https://lists.fedoraproject.org/archives/list/openscanhub@lists.fedoraprojec...
https://openscanhub.fedoraproject.org/task/%3E
https://fedoraproject.org/wiki/OpenScanHub%3E
-- Siteshwar Vashisht
On Wednesday, July 10, 2024 7:14:56 AM CEST Tom Stellard wrote:
On 7/5/24 17:05, 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.
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!
The scan for LLVM reported 0 issues, which seems unlikely. Is it possible the scan timed out? We run the clang static analyzer upstream and it does report issues: https://github.com/llvm/llvm-project/actions/runs/9866302541/job/27244829483
-Tom
Thank you for pointing it out! The compiler wrapper that OSH uses did not support packages that use clang/clang++ as the system compiler. The following pull request should fix this: https://github.com/csutils/cscppc/pull/43
Kamil
[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OMKLJFW4VC242QSA7R4KMGI6IGBT3YLM/ [2] https://svashisht.fedorapeople.org/f41-03-Jul-2024/ https://svashisht.fedorapeople.org/f41-03-Jul-2024/ [3] https://lists.fedoraproject.org/archives/list/openscanhub@lists.fedoraprojec... https://lists.fedoraproject.org/archives/list/openscanhub@lists.fedoraproject.org/ [4] https://openscanhub.fedoraproject.org/task/ https://openscanhub.fedoraproject.org/task/ [5] https://fedoraproject.org/wiki/OpenScanHub https://fedoraproject.org/wiki/OpenScanHub
-- Siteshwar Vashisht
openscanhub@lists.fedoraproject.org
-
Daniel P. Berrangé -
David Malcolm -
Kamil Dudka -
Siteshwar Vashisht -
Tom Stellard