Errors seen in LOGS/postgresql-9.1.2-2.fc17

This is a summary of errors seen when compiling with an experimental static analysis tool

Raw build logs can be seen here

Unclassified errors

The triager didn't know how to classify these ones

plpython.c PLy_output passing uninitialized data (o.278) as argument 1 to function at plpython.c:4236

Segfaults in normal paths

Code paths that will lead to a segmentatation fault

plpython.c get_source_line dereferencing NULL (*s) at plpython.c:4569

Reference count too low

Code paths in which the reference count of an object is left too low. This could lead to the object being deallocated too early, triggering segfaults when later accessed. Over repeated calls, these errors could accumulate, increasing the likelihood of a segfault.

plpython.c PLy_init_interp ob_refcnt of '*PLy_interp_globals' is 1 too low

Reference count too low within an initialization routine

Code paths in which the reference count of an object is too low, but within an initialization routine, and thus likely to only happen once

plpython.c PLy_generate_spi_exceptions ob_refcnt of '*exc' is 1 too low

Reference leak within initialization

Code paths in which the reference count of an object is left too high, but within an initialization routine, and thus likely to only happen once

plpython.c PLy_generate_spi_exceptions ob_refcnt of '*dict' is 1 too high
plpython.c PLy_add_exceptions ob_refcnt of '*PLy_exc_spi_error' is 1 too high
plpython.c PLy_add_exceptions ob_refcnt of '*PLy_exc_fatal.302' is 1 too high
plpython.c PLy_add_exceptions ob_refcnt of '*PLy_exc_error.304' is 1 too high

Segfaults within error-handling paths

Code paths in error-handling that will lead to a segmentatation fault (e.g. under low memory conditions)

plpython.c PLy_init_interp calling PyDict_SetItemString with NULL as argument 3 (PLy_interp_safe_globals.6) at plpython.c:4127
plpython.c PLy_init_interp dereferencing NULL (mainmod->ob_refcnt) at plpython.c:4124
plpython.c PLy_generate_spi_exceptions calling PyDict_SetItemString with NULL as argument 3 (sqlstate) at plpython.c:3971
plpython.c PLyList_FromArray dereferencing NULL (MEM[(struct PyListObject *)list].ob_item) at plpython.c:2362
plpython.c PLyList_FromArray dereferencing NULL (MEM[(struct PyListObject *)list].ob_item) at plpython.c:2365
plpython.c PLy_init_plpy calling PyDict_SetItemString with NULL as argument 3 (plpy_mod) at plpython.c:4167
plpython.c PLy_add_exceptions dereferencing NULL (PLy_exc_spi_error.306->ob_refcnt) at plpython.c:4015
plpython.c PLy_add_exceptions dereferencing NULL (PLy_exc_fatal.305->ob_refcnt) at plpython.c:4013
plpython.c PLy_add_exceptions dereferencing NULL (PLy_exc_error.304->ob_refcnt) at plpython.c:4011
plpython.c PLyUnicode_AsString calling PyString_AsString with NULL as argument 1 (o) at plpython.c:4875
plpython.c PLyDict_FromTuple calling PyDict_SetItemString with NULL as argument 3 (value) at plpython.c:2404

Possible reference leaks

Code paths in which the reference count of an object might too large - but in which the reference in question came from a function not known to the analyzer.

The analyzer assumes such references are new references, but if the function returns a borrowed reference instead, it's probably not a bug

plpython.c PLy_spi_execute_query ob_refcnt of '*ret' is 1 too high

Returning (PyObject*)NULL without setting an exception

These messages are often false-positives: the analysis tool has no knowledge about internal API calls that can lead to an exception being set
plpython.c PLy_output returning (PyObject*)NULL without setting an exception
plpython.c PLy_subtransaction_enter returning (PyObject*)NULL without setting an exception
plpython.c PLy_spi_execute_query returning (PyObject*)NULL without setting an exception
plpython.c PLy_subtransaction_exit returning (PyObject*)NULL without setting an exception

Implementation notes for gcc-with-cpychecker

The following "Py" functions were used but aren't yet explicitly handled by gcc-with-cpychecker