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);
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.
/Geoff
On Fri, Oct 4, 2019 at 9:56 PM MRAB <pyt...@mrabarnett.plus.com> wrote:
> On 2019-10-04 20:32, Geoff Bache wrote:
> > Hi all,
> >
> > We are running Python embedded in our C++ product and are now
> experiencing
> > crashes (access violation reading 0xffffffffff on Windows) in the Python
> > garbage collector.
> >
> > We got this on Python 3.6.4 originally, but I can reproduce it with both
> > Python 3.6.8 and Python 3.7.4.
> >
> > The chances of producing a minimal example that reproduces it reliably
> are
> > currently small I would say. All attempts to simplify the set up seem to
> > cause the problem to go away.
> > Indeed I can only reproduce it by sending a fairly large amount of data 2
> > or 3 times to our server - sending either half of the data does not
> > reproduce it.
> >
> [snip]
> In my experience, it's most likely caused by incorrect refcounting,
> DECREFing too many times.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
