Postgresql and Clang Static Analyzer

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

​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 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/&gt;

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&gt;

--
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/&gt;

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&gt;

--
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