[issue3399] Memory corruption in multiprocessing module, OS X 10.5.4
Mark Dickinson
report at bugs.python.org
Fri Aug 1 15:51:01 CEST 2008
Mark Dickinson <dickinsm at gmail.com> added the comment:
I finally found some more time to look at this. I cut down the test-suite
to try to find a minimal failing example. I can fairly reliably make a
debug build of the trunk crash using the following nine lines
import multiprocessing.managers
def sqr(x): return x*x
manager = multiprocessing.managers.SyncManager()
manager.start()
pool = manager.Pool(4)
it = pool.imap_unordered(sqr, range(10000))
assert sorted(it) == map(sqr, range(10000))
pool.terminate()
manager.shutdown()
Typical output is:
Fatal Python error: UNREF invalid object
(followed by traceback)
or:
Assertion failed: (bp != NULL), function PyObject_Malloc, file
Objects/obmalloc.c, line 755.
or:
Debug memory block at address p=0x247778:
26 bytes originally requested
The 4 pad bytes at p-4 are not all FORBIDDENBYTE (0xfb):
at p-4: 0xdb *** OUCH
at p-3: 0xdb *** OUCH
at p-2: 0xdb *** OUCH
at p-1: 0xdb *** OUCH
Because memory is corrupted at the start, the count of bytes requested
may be bogus, and checking the trailing pad bytes may segfault.
The 4 pad bytes at tail=0x247792 are not all FORBIDDENBYTE (0xfb):
at tail+0: 0x35 *** OUCH
at tail+1: 0x00 *** OUCH
at tail+2: 0xfb
at tail+3: 0xfb
The block was made by call #4227530756 to debug malloc/realloc.
Data at p: 00 00 00 00 00 00 00 00 ... 00 00 08 00 00 00 b0 72
Fatal Python error: bad leading pad byte
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3399>
_______________________________________
More information about the Python-bugs-list
mailing list