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
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
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 > https://github.com/matplotlib/ (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
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 >> https://github.com/matplotlib/ (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 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