Access violation in Python garbage collector (visit_decref) - how to debug?

[MRAB]

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]