On Sep 9, 2004, at 2:21 PM, Tim Peters wrote:
[Dieter Maurer]
I checked the "Py_BuildValue" occurrences in the "BTrees" package.
I am quite convinced that they cannot show this behaviour unless your computer executes different code than coded there.
That's good to hear. I went thru the same exercise the first time I saw one of these reported, and came to the same conclusion. It doesn't, however, rule out compiler optimization bugs. Seems unlikely, but when the reported symptom is impossible, "unlikely" is attractive by comparison <wink>.
I would try to analyse the problem as follows:
* catch the exception and use "import pdb; pdb.set_trace()" in the except clause
* run Zope in the foreground until the error occurs and Zope stops in "set_trace()".
* attach the Zope process with GDB (or another debugger able to attach a running process
* put a GDB breakpoint on "Py_BuildValue"
* continue execution
* use "pdb" to reexecute "object.__getstate()__"
When your problem is deterministic, it will occur again.
You will stop in "Py_BuildValue". Continue until "Py_BuildValue" is called with a "NULL" value. Analyse the backtrace.
Calling object._check() could also be informative. For example, if we have a multi-bucket BTree, the
ASSIGN(r, Py_BuildValue("OO", r, self->firstbucket));
line assumes (but does not verify) that self->firstbucket is non-NULL. If it is in fact NULL, Py_BuildValue would complain about that, and so would ._check().
thanks guys for all of your help. i will study these tips and attempt to implement them in hopes of catching what's going wrong. hopefully it was a fluke, but i'd surely feel more comfortable if it was reproducible. thanks, travis