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

[Geoff Bache]

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 <python at 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
>