git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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]