Thread: [BUGS] Postgresql and Clang Static Analyzer
Hello, I compiled postgresql with PYTHON=/usr/local/bin/python3 scan-build ./configure --with-perl --with-tcl --with-gssapi --with-ldap --with-openssl --with-libxml --with-libxslt --with-systemd --with-python scan-build make and here are the results: https://mail.aegee.org/dpa/scan-build-pg-b3a47cdfd6/ Please note, that the information is only about what gets actually compiled, code disabled by #if .. #endif is not considered (e.g. when determining whether a variable assignment is useless). There are probably some false-positives. I used scan-build/clang 4.0. Enjoy Дилян -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Hello,
I compiled postgresql with
PYTHON=/usr/local/bin/python3 scan-build ./configure --with-perl --with-tcl --with-gssapi --with-ldap --with-openssl --with-libxml --with-libxslt --with-systemd --with-python
scan-build make
and here are the results:
https://mail.aegee.org/dpa/scan-build-pg-b3a47cdfd6/
Please note, that the information is only about what gets actually compiled, code disabled by #if .. #endif is not considered (e.g. when determining whether a variable assignment is useless). There are probably some false-positives.
I used scan-build/clang 4.0.
Enjoy
We much prefer if emails to bugs are self-contained and not pointing to some random web URL which cautious people aren't going to follow. It would also be helpful to actually state in your own words what you believe the bug is/what the correct behavior should be.
David J.
This by itself doesn't prove the existence of a bug, while it's a useful tool to find pieces of code which MIGHT be a problem, it doesn't prove that every instance is an actual bug :)
Clang-Analyzer and other static analysis tools are useful when used with actually reading the code in question (I've found bugs which clang-analyzer has actually missed in other software projects)
On Fri, May 5, 2017 at 2:36 PM, Дилян Палаузов <dpa-postgres@aegee.org> wrote:
Hello,
I compiled postgresql with
PYTHON=/usr/local/bin/python3 scan-build ./configure --with-perl --with-tcl --with-gssapi --with-ldap --with-openssl --with-libxml --with-libxslt --with-systemd --with-python
scan-build make
and here are the results:
https://mail.aegee.org/dpa/scan-build-pg-b3a47cdfd6/
Please note, that the information is only about what gets actually compiled, code disabled by #if .. #endif is not considered (e.g. when determining whether a variable assignment is useless). There are probably some false-positives.
I used scan-build/clang 4.0.
Enjoy
Дилян
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Hello, I provided the analysis for your information, without stating whether there are bugs. I think most reported stuff is justified, e.g. in src/backend/storage/smgr/md.c:875 the initialization seems to be indeed superflous. Likewise for the assignment on src/interfaces/libpq/fe-print.c:347. It is not hard to click through the links and verify, whether they are false positives, when you know how the code is structured. You can use lynx if you want to exclude any danger. I wouldn't have a problem if you ignore the analysis. Regards Дилян On 05/05/2017 11:41 PM, Bill Parker wrote: > This by itself doesn't prove the existence of a bug, while it's a useful > tool to find pieces of code which MIGHT be a problem, it doesn't prove > that every instance is an actual bug :) > > Clang-Analyzer and other static analysis tools are useful when used with > actually reading the code in question (I've found bugs which > clang-analyzer has actually missed in other software projects) > > On Fri, May 5, 2017 at 2:36 PM, Дилян Палаузов <dpa-postgres@aegee.org > <mailto:dpa-postgres@aegee.org>> wrote: > > Hello, > > I compiled postgresql with > > PYTHON=/usr/local/bin/python3 scan-build ./configure --with-perl > --with-tcl --with-gssapi --with-ldap --with-openssl --with-libxml > --with-libxslt --with-systemd --with-python > > scan-build make > > and here are the results: > https://mail.aegee.org/dpa/scan-build-pg-b3a47cdfd6/ > <https://mail.aegee.org/dpa/scan-build-pg-b3a47cdfd6/> > > > Please note, that the information is only about what gets actually > compiled, code disabled by #if .. #endif is not considered (e.g. > when determining whether a variable assignment is useless). There > are probably some false-positives. > > I used scan-build/clang 4.0. > > Enjoy > Дилян > > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org > <mailto:pgsql-bugs@postgresql.org>) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs > <http://www.postgresql.org/mailpref/pgsql-bugs> > > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
For the record, I added --enable-cassert, which reduced the hints by 59. PYTHON=/usr/local/bin/python3 scan-build ./configure --prefix=/usr/local --with-perl --with-tcl --with-gssapi --with-ldap --with-openssl --with-libxml --with-libxslt --with-systemd --with-python --enable-cassert scan-build make and the output is at https://mail.aegee.org/dpa/scan-build-pg-628462bda9/ On 05/06/2017 10:31 PM, Дилян Палаузов wrote: > Hello, > > I provided the analysis for your information, without stating whether > there are bugs. > > I think most reported stuff is justified, e.g. in > src/backend/storage/smgr/md.c:875 the initialization seems to be indeed > superflous. Likewise for the assignment on > src/interfaces/libpq/fe-print.c:347. > > It is not hard to click through the links and verify, whether they are > false positives, when you know how the code is structured. > > You can use lynx if you want to exclude any danger. > > I wouldn't have a problem if you ignore the analysis. > > Regards > Дилян > > On 05/05/2017 11:41 PM, Bill Parker wrote: >> This by itself doesn't prove the existence of a bug, while it's a useful >> tool to find pieces of code which MIGHT be a problem, it doesn't prove >> that every instance is an actual bug :) >> >> Clang-Analyzer and other static analysis tools are useful when used with >> actually reading the code in question (I've found bugs which >> clang-analyzer has actually missed in other software projects) >> >> On Fri, May 5, 2017 at 2:36 PM, Дилян Палаузов <dpa-postgres@aegee.org >> <mailto:dpa-postgres@aegee.org>> wrote: >> >> Hello, >> >> I compiled postgresql with >> >> PYTHON=/usr/local/bin/python3 scan-build ./configure --with-perl >> --with-tcl --with-gssapi --with-ldap --with-openssl --with-libxml >> --with-libxslt --with-systemd --with-python >> >> scan-build make >> >> and here are the results: >> https://mail.aegee.org/dpa/scan-build-pg-b3a47cdfd6/ >> <https://mail.aegee.org/dpa/scan-build-pg-b3a47cdfd6/> >> >> >> Please note, that the information is only about what gets actually >> compiled, code disabled by #if .. #endif is not considered (e.g. >> when determining whether a variable assignment is useless). There >> are probably some false-positives. >> >> I used scan-build/clang 4.0. >> >> Enjoy >> Дилян >> >> >> -- >> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org >> <mailto:pgsql-bugs@postgresql.org>) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-bugs >> <http://www.postgresql.org/mailpref/pgsql-bugs> >> >> -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Hello, > and the output is at > https://mail.aegee.org/dpa/scan-build-pg-628462bda9/ I had a quick look on 'src/bin/pgbench/pgbench.c' 4 warnings: One seems indeed to be an unused assignment ("command" variable assignment on line 2286) and could be removed, although a cleaner solution would be to use per-block "command" variables instead of a shared global one, but pg switch indentation rules would shift the code too much to my taste. The other three about undefined variables just demonstrate that clang does not understand the code: it does not get that the argc counter counts arguments so that it is fine to use the corresponding offsets (while loop on 3301, uses afterwards). The fact could be hidden from clang by zero filling the offset array to make clang believe that the array is initialized, but that would be just reassuring it without really improving anything. None of these four issues are "bugs" in any sense, IMHO, they just proove that static analysis can generate more noise than signal when applied roughtly. -- Fabien. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
On 5/6/17 16:31, Дилян Палаузов wrote: > I provided the analysis for your information, without stating whether > there are bugs. We are aware of scan-build and do use it. At this point, the easy issues have probably already been cleaned up. If you want to dig into the issues it reports and have ideas for improvements, that would be appreciated. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs