Re: [matplotlib-devel] Coverity defects in python-basemap

[Benjamin R. <ben...@ou...>]

2011/7/28 Pavel Raiskup <pra...@re...>

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