Access violation in Python garbage collector (visit_decref) - how to debug?
MRAB
python at mrabarnett.plus.com
Mon Oct 7 13:30:53 EDT 2019
On 2019-10-07 08:04, Geoff Bache wrote:
> It's possible. Our embedding code is fairly simple and we've tried to
> encapsulate all the DECREFing in resource objects, i.e. that do DECREF
> in their destructor when they go out of scope. We hoped this would
> minimise this sort of problem.
> The C++ calling code essentially tries to call progwrapper.prog with a
> dictionary as arguments, and looks like
>
> GilStateHolder pyStateHolder;
> PyRefHolder module(PyImport_ImportModule("progwrapper"));
>
> if (module._ref)
> {
> PyXRefHolder func(PyObject_GetAttrString(module._ref, "prog"));
> PyXRefHolder pyArgs(PyTuple_New(1));
> PyXRefHolder pyDict(convertDictForPython(dictIn));
> PyTuple_SetItem(pyArgs._ref, 0, pyDict._ref);
|Do you DECREF pyDict._ref later on? I ask because PyTuple_SetItem
steals a reference.|
|Many other functions that "store" an object, such as PyList_Append,
INCREF to retain the stored object, but PyTuple_SetItem doesn't.|
||
> PyRefHolder pyRet(PyObject_CallObject(func._ref, pyArgs._ref));
>
> if (pyRet._ref != NULL)
> {
> addPythonValuesToDict(pyRet._ref, theDict);
> ...
>
> where GilStateHolder, PyRefHolder etc are such resource objects as
> described above, wrapping round the PyObject pointers etc.
>
> [snip]
More information about the Python-list
mailing list