On Mon, Jan 11, 2016 at 6:55 PM, Rickard Englund <gefle.rick...@gmail.com> wrote: > On Friday, January 8, 2016 at 11:28:53 PM UTC+1, Michael Torrie wrote: >> On 01/08/2016 09:18 AM, Rickard Englund wrote: >> > First, some system info >> > * Windows 7 (also tested on 8 and 10) >> > * Python 3.5.1 64bit (previously also tested using several 3.x versions) >> > (also tested with 32 bit, but with 3.4.2) >> > * Microsoft Visual Studio 2015 (earlier version of python also tested with >> > Visual Studio 2013) >> >> Are you using the same version of Visual Studio that Python itself was >> compiled with? If not there can be subtle problems with incompatible >> msvcrt dlls. No idea if this would be contributing to the problem or >> not, though. > > I've just downloaded the python source code and build it myself, the compiler > settings in our project is the same as in the python projects. > > > Though, your comment led me in the correct direction. When using the > libs/binary I built my self it let me see the values of the PyObjects around > the crash and it seems like it is related to our modules and/or how we expose > them to the interpreter. When disabling our own modules everything seems to > be working as it should. >
Interesting. So somewhere along the way, you have native code (C code?) that's creating a module, and that's where the trouble starts? I would first look at all your refcount management; if that goes wrong, all sorts of craziness could happen (if you still have a pointer to a block of memory that gets released and reused, hilarity will ensue - or, something will). Have you considered using Cython? That might let you do what you need without worrying about all those annoying internal API details. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
