This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author steve.dower
Recipients jnoller, sbt, steve.dower, tim.golden, zach.ware
Date 2014-12-16.02:29:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1418696995.02.0.22756137648.issue23060@psf.upfronthosting.co.za>
In-reply-to
Content
Currently, the implementation of __setstate__ at Lib/multiprocessing/heap.py:54 looks like this:

def __setstate__(self, state):
    self.size, self.name = self._state = state
    self.buffer = mmap.mmap(-1, self.size, tagname=self.name)
    assert _winapi.GetLastError() == _winapi.ERROR_ALREADY_EXISTS

This assertion can fail when the assignment to buffer triggers memory [re]allocation, which could clear the last error result. So far, this fails reliably on debug builds using VS 2015 (which causes some tests to timeout when all of the child processes fail to start), but could also fail in threaded code at any time.

I don't know why release builds or builds with VS 2010 did not trigger this, but I would speculate that either VS 2015 is using a different API to allocate memory or Windows 8.1 has changed the behaviour of an API. Whether a function resets the last error code is deliberately unspecified (http://msdn.microsoft.com/en-us/library/windows/desktop/ms679360(v=vs.85).aspx - "some functions set the last-error code to 0 on success and others do not").

In my opinion, the assertion should just be removed.

A hack that appears to work currently is to add "self.buffer = None" before the existing assignment (to pre-expand self.__dict__ and avoid the allocation).

If the assertion is important, someone may want to add a parameter to mmap() to require that the memory-mapped file already exists and throws otherwise, but I am not volunteering to do this.
History
Date User Action Args
2014-12-16 02:29:55steve.dowersetrecipients: + steve.dower, tim.golden, jnoller, sbt, zach.ware
2014-12-16 02:29:55steve.dowersetmessageid: <1418696995.02.0.22756137648.issue23060@psf.upfronthosting.co.za>
2014-12-16 02:29:54steve.dowerlinkissue23060 messages
2014-12-16 02:29:53steve.dowercreate