string key (and probably a few other situations with string keys).
This was reported with a patch as pybsddb sourceforge bug 1708868 by
jjjhhhlll at gmail.
Different versions of Berkeley DB handle this differently.
The comments and bug report should have the details. Memory is allocated
in 4.4 (and presumably earlier), but not in 4.5. Thus
4.5 has the free error, but not earlier versions.
Mostly update comments, plus make the free conditional.
This fix was already applied to the 2.5 branch.
The problem is that _DB_get_type() can't be called without the GIL
because it calls a bunch of PyErr_* APIs when an error occurs.
There were no other cases in this file that it was called without the GIL.
Removing the BEGIN/END THREAD around _DB_get_type() made everything work.
Will backport.
it definitely could use some review to ensure I'm not off by one
and there's no possible overflow/wrap-around of bytes_left.
Reported by Klocwork #1.
Fix a problem if there is a failure allocating self->db.
Found with failmalloc.
parameter strings") changed this function's signature
seemingly by mistake, which is causing buildbots to fail
test_bsddb3. Restored the pre-46688 signature.
in BerkeleyDB >= 4.2 it tried to construct a list out of an uninitialized
char **log_list.
feature: export the DB_ARCH_REMOVE flag by name in the module on BerkeleyDB >= 4.2.
missing PyObject_Del()'s, simplify some code by using Py_BuildValue()
instead of creating a tuple with items manually, stop clobbering builtin
exceptions in a few places, and guard against NULL-returning functions some
more.
This fixes 117 of the 780 (!?!#%@#$!!) reference leaks in test_bsddb3. I
ain't not done yet, although this review of 5kloc was just the easy part.
non-32bit platforms. Will still only allow 32 bits in a timestamp on Win64,
but at least it won't crash, and it'll work right on platforms where longs
are big enough to contain time_t's.
(A better-working, although conceptually less-right fix would have been to
use Py_ssize_t here, but Martin and Tim won't let me.)
In C++, it's an error to pass a string literal to a char* function
without a const_cast(). Rather than require every C++ extension
module to put a cast around string literals, fix the API to state the
const-ness.
I focused on parts of the API where people usually pass literals:
PyArg_ParseTuple() and friends, Py_BuildValue(), PyMethodDef, the type
slots, etc. Predictably, there were a large set of functions that
needed to be fixed as a result of these changes. The most pervasive
change was to make the keyword args list passed to
PyArg_ParseTupleAndKewords() to be a const char *kwlist[].
One cast was required as a result of the changes: A type object
mallocs the memory for its tp_doc slot and later frees it.
PyTypeObject says that tp_doc is const char *; but if the type was
created by type_new(), we know it is safe to cast to char *.
Neal Norwitz
Gregory P. Smith
Martin v. Löwis
Kristján Valur Jónsson
Tim Peters
Georg Brandl
Thomas Wouters
Jeremy Hylton