I am calling a python method from C using the attached code.

The Site.py file is:

import os

def find_site():
    path = os.path.abspath(".")
    return path

Cross compiled to Windows from Linux using mxe.cc and python 2.7.17
On 32-bit this runs as expected:

module = 028BC710
result = 0283D6B0
Found Site at \\wsl$\Ubuntu\home\dl
result = 0283D6B0 decref
module = 028BC710 decref

Site = \\wsl$\Ubuntu\home\dl
but crashes on 64-bit, failing to DECREF result:

module = 0000000002750408
result = 0000000000E62EF0
Found Site at \\wsl$\Ubuntu\home\dl
result = 0000000000E62EF0 decref

In both cases the libpython was made using the .dll copied from the target Windows machine and pexports and dlltool to create the .a

 if the return value of the python is return "C:/Test/Path" it works. if you add test2 = test and return test2 it fails. if you say test2 = "".join(c for c in path) and return test2 it fails. if you set path2 = "C:/Test/Path and return test2 it works

using Py_REFCNT [in the C code] shows a value of 2 for a return "c:/test" but a value of 1 a return test

further investigation seems to point to this being something to do with mingw and the dll. I have tried compiling the same test example on 64-bit linux and in the Ubuntu WSL on windows and it works. Tests also show that the refcount of '1' is correct and not the problem.
the PyObject pointers of 0000000002750408 are suspicious though and on sight look like 32-bit addresses -- is there some odd 32/64 bit mismatch happening somewhere even though the lib clearly links and loads the dll?

by redefinining the Py_DECREF macro in my application:

#define  Py_DECREF(op) do { if (--op->ob_refcnt == 0) fprintf(stderr, "DECREF %s %d %p %d %s %p\n", __FILE__, __LINE__, op, Py_SIZE(op), Py_TYPE(op)->tp_name,Py_TYPE(op)->tp_dealloc );  fflush(stderr); } while(0)

this outputs lines like this:

DECREF vardef_file.cc 1601 0000000009F3C728 0 generator 0000000000000000

which appears to be showing the tp_dealloc is a null pointer.

traced to be a duplicate of https://bugs.python.org/issue28267