[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