Coverity defects in python-basemap

Development matplotlib-devel
1

Hi,

I would like to report some issues in python basemap package and easy-fixes for
some of them. We would really appreciate if there was somebody who could look
on this and consider important bugs to be fixed.

These bugs was found by Coverity scan and we have ran it on Fedora 15
packages (srpm). There was some findings in python basemap package also. Coverity
is proprietary software but we can give its result to community (if interrested),
possibly we can re-run some tests on srpms on demand.

Patch for next three obvious bugs (plaintext cov. output) is attached:

Error: OVERRUN_STATIC:
basemap-0.99.4/src/pj_gridlist.c:252: overrun-local: Overrunning static array "name", with 128 elements, at position 128 with index variable "end_char".

Error: UNINIT:
basemap-0.99.4/src/mk_cheby.c:42: var_decl: Declaring variable "T" without initializer.
basemap-0.99.4/src/mk_cheby.c:150: uninit_use: Using uninitialized value "T".
basemap-0.99.4/src/mk_cheby.c:151: uninit_use: Using uninitialized value "T->mu".
basemap-0.99.4/src/mk_cheby.c:152: uninit_use: Using uninitialized value "T->cu".
basemap-0.99.4/src/mk_cheby.c:154: uninit_use: Using uninitialized value "T->mv".
basemap-0.99.4/src/mk_cheby.c:155: uninit_use: Using uninitialized value "T->cv".
basemap-0.99.4/src/mk_cheby.c:163: uninit_use: Using uninitialized value "T".

Error: NO_EFFECT:
basemap-0.99.4/src/PJ_sconics.c:52: self_assign: Assignment operation "*del = *del" has no effect.

CoverityScan-defects.patch (1.13 KB)

···

__________________________

But there is more defects (or coding style issues) and some of them are not
so obvious. There could be potential problems -- need to be consulted, e.g.:

Error: EVALUATION_ORDER:
basemap-0.99.4/src/PJ_stere.c:232: write_write_order: In "P->phits = (pj_param(P->params, "tlat_ts").i ? P->phits = pj_param(P->params, "rlat_ts").f : 1.5708)", "P->phits" is written in "P->phits" (the assignment left-hand side) and written in "pj_param(P->params, "tlat_ts").i ? P->phits = pj_param(P->params, "rlat_ts").f : 1.5708" but the order in which the side effects take place is undefined because there is no intervening sequence point.

Error: FORWARD_NULL:
basemap-0.99.4/src/emess.c:29: var_compare_op: Comparing "fmt" to null implies that "fmt" might be null.
basemap-0.99.4/src/emess.c:51: var_deref_model: Passing null variable "fmt" to function "vfprintf", which dereferences it.

Error: FORWARD_NULL:
basemap-0.99.4/src/pj_gridinfo.c:505: var_compare_op: Comparing "gp" to null implies that "gp" might be null.
basemap-0.99.4/src/pj_gridinfo.c:512: alias_transfer: Assigning null: "lnk" = "gp".
basemap-0.99.4/src/pj_gridinfo.c:512: var_deref_op: Dereferencing null variable "lnk".

Error: FORWARD_NULL:
basemap-0.99.4/src/pj_ell_set.c:30: var_compare_op: Comparing "start->next" to null implies that "start->next" might be null.
basemap-0.99.4/src/pj_ell_set.c:92: var_deref_op: Dereferencing null variable "start->next".

Coverity test was done on:
http://sourceforge.net/projects/matplotlib/files/matplotlib-toolkits/basemap-0.99.4/basemap-0.99.4.tar.gz

..so svn version is little different (line numbers) but it can be handy for
finding hidden bugs. I can send you full plain-text log if you want.

Pavel

2

2011/7/28 Pavel Raiskup <praiskup@…999…>

Hi,

I would like to report some issues in python basemap package and easy-fixes for

some of them. We would really appreciate if there was somebody who could look

on this and consider important bugs to be fixed.

These bugs was found by Coverity scan and we have ran it on Fedora 15

packages (srpm). There was some findings in python basemap package also. Coverity

is proprietary software but we can give its result to community (if interrested),

possibly we can re-run some tests on srpms on demand.

Patch for next three obvious bugs (plaintext cov. output) is attached:

Error: OVERRUN_STATIC:

basemap-0.99.4/src/pj_gridlist.c:252: overrun-local: Overrunning static array “name”, with 128 elements, at position 128 with index variable “end_char”.

Error: UNINIT:

basemap-0.99.4/src/mk_cheby.c:42: var_decl: Declaring variable “T” without initializer.

basemap-0.99.4/src/mk_cheby.c:150: uninit_use: Using uninitialized value “T”.

basemap-0.99.4/src/mk_cheby.c:151: uninit_use: Using uninitialized value “T->mu”.

basemap-0.99.4/src/mk_cheby.c:152: uninit_use: Using uninitialized value “T->cu”.

basemap-0.99.4/src/mk_cheby.c:154: uninit_use: Using uninitialized value “T->mv”.

basemap-0.99.4/src/mk_cheby.c:155: uninit_use: Using uninitialized value “T->cv”.

basemap-0.99.4/src/mk_cheby.c:163: uninit_use: Using uninitialized value “T”.

Error: NO_EFFECT:

basemap-0.99.4/src/PJ_sconics.c:52: self_assign: Assignment operation “*del = *del” has no effect.

But there is more defects (or coding style issues) and some of them are not

so obvious. There could be potential problems – need to be consulted, e.g.:

Error: EVALUATION_ORDER:

basemap-0.99.4/src/PJ_stere.c:232: write_write_order: In “P->phits = (pj_param(P->params, “tlat_ts”).i ? P->phits = pj_param(P->params, “rlat_ts”).f : 1.5708)”, “P->phits” is written in “P->phits” (the assignment left-hand side) and written in “pj_param(P->params, “tlat_ts”).i ? P->phits = pj_param(P->params, “rlat_ts”).f : 1.5708” but the order in which the side effects take place is undefined because there is no intervening sequence point.

Error: FORWARD_NULL:

basemap-0.99.4/src/emess.c:29: var_compare_op: Comparing “fmt” to null implies that “fmt” might be null.

basemap-0.99.4/src/emess.c:51: var_deref_model: Passing null variable “fmt” to function “vfprintf”, which dereferences it.

Error: FORWARD_NULL:

basemap-0.99.4/src/pj_gridinfo.c:505: var_compare_op: Comparing “gp” to null implies that “gp” might be null.

basemap-0.99.4/src/pj_gridinfo.c:512: alias_transfer: Assigning null: “lnk” = “gp”.

basemap-0.99.4/src/pj_gridinfo.c:512: var_deref_op: Dereferencing null variable “lnk”.

Error: FORWARD_NULL:

basemap-0.99.4/src/pj_ell_set.c:30: var_compare_op: Comparing “start->next” to null implies that “start->next” might be null.

basemap-0.99.4/src/pj_ell_set.c:92: var_deref_op: Dereferencing null variable “start->next”.

Coverity test was done on:

http://sourceforge.net/projects/matplotlib/files/matplotlib-toolkits/basemap-0.99.4/basemap-0.99.4.tar.gz

…so svn version is little different (line numbers) but it can be handy for

finding hidden bugs. I can send you full plain-text log if you want.

Pavel

Pavel,

Coverity is an interesting product and I heard of it before on TheDailyWTF.com (in positive light, of course!). However, it appears that you were scanning an outdated version of our software. The current release version is v1.0.1, and we are poised to do another release soon. The current version of our software can be found at https://github.com/matplotlib/ (there are separate matplotlib and basemap repos). I would certainly be interested in the results on that.

However, if RedHat is interested in packaging matplotlib in a release of RHEL (I know a lot of people at NOAA, NWS and NSSL who would appreciate that) and there is a particular version of matplotlib that you have selected for packaging, we can certainly work with you on that.

Ben Root

3

Hi,

Coverity is an interesting product and I heard of it before on
TheDailyWTF.com (in positive light, of course!). However, it appears that
you were scanning an outdated version of our software. The current release
version is v1.0.1, and we are poised to do another release soon. The
current version of our software can be found at
Matplotlib Developers · GitHub (there are separate matplotlib and basemap
repos). I would certainly be interested in the results on that.

Hi, I've checked last results of coverity against svn version and these filtered
defects are present there also (not only in version 0.9.4) but I have made new
scan for you on trunk code. The coverity error log is attached.

   python-basemap-1.0.2.err (defects in hand-written source)
   python-basemap-1.0.2.gc (defects in generated code)

However, if RedHat is interested in packaging matplotlib in a release of
RHEL (I know a lot of people at NOAA, NWS and NSSL who would appreciate
that) and there is a particular version of matplotlib that you have selected
for packaging, we can certainly work with you on that.

We are not currently planning packaging matplotlib in RHEL. Coverity's scans are
done on wide range of package canditates for next RHEL but it does not necessary
mean that matplotlib will be included. There is long way to this yet.. and
I can not affect this unfortunately.

Howeever, if you would like to help with packaging in Fedora, you could try to
contact python-basemap's maintainer in Fedora.

Thank you,
Pavel

python-basemap-1.0.2.err (55.5 KB)

python-basemap-1.0.2.gc (12.6 KB)

4

These warnings all are either in cython generated code, or proj4 library code. Since cython code is automatically generated, I can't fix those. I don't want to change the proj4 library routines either, since they are externally maintained.

-Jeff

···

On 8/11/11 4:11 AM, Pavel Raiskup wrote:

Hi,

Coverity is an interesting product and I heard of it before on
TheDailyWTF.com (in positive light, of course!). However, it appears that
you were scanning an outdated version of our software. The current release
version is v1.0.1, and we are poised to do another release soon. The
current version of our software can be found at
Matplotlib Developers · GitHub (there are separate matplotlib and basemap
repos). I would certainly be interested in the results on that.

Hi, I've checked last results of coverity against svn version and these filtered
defects are present there also (not only in version 0.9.4) but I have made new
scan for you on trunk code. The coverity error log is attached.

  python-basemap-1.0.2.err (defects in hand-written source)
  python-basemap-1.0.2.gc (defects in generated code)

However, if RedHat is interested in packaging matplotlib in a release of
RHEL (I know a lot of people at NOAA, NWS and NSSL who would appreciate
that) and there is a particular version of matplotlib that you have selected
for packaging, we can certainly work with you on that.

We are not currently planning packaging matplotlib in RHEL. Coverity's scans are
done on wide range of package canditates for next RHEL but it does not necessary
mean that matplotlib will be included. There is long way to this yet.. and
I can not affect this unfortunately.

Howeever, if you would like to help with packaging in Fedora, you could try to
contact python-basemap's maintainer in Fedora.

Thank you,
Pavel