[Zope] Py_BuildValue Error

[Travis Miller]

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