[Python-Dev] Regression in unicodestr.encode()? (original) (raw)
Tim Peters tim.one@comcast.net
Wed, 10 Apr 2002 15:34:06 -0400
- Previous message: [Python-Dev] Regression in unicodestr.encode()?
- Next message: [Python-Dev] Regression in unicodestr.encode()?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
... Looks like a pymalloc problem to me. Tim ?
I doubt it, but haven't spent much time on it. If you run Barry's test under a debug build, a call to pymalloc's realloc complains immediately upon entry that the passed-in address suffered overwrites (i.e., whoever malloc'ed or realloc'ed this area the preceding time wrote into positions beyond the number of bytes they asked for):
Debug memory block at address p=00864280: 180 bytes originally allocated the 4 pad bytes at p-4 are PYMALLOC_FORBIDDENBYTE, as expected the 4 pad bytes at tail=00864334 are not all PYMALLOC_FORBIDDENBYTE (0xfb): at tail+0: 0x69 *** OUCH at tail+1: 0x74 *** OUCH at tail+2: 0x20 *** OUCH at tail+3: 0x75 *** OUCH the block was made by call #1852047475 to debug malloc/realloc data at p: 00 00 00 00 00 00 00 00 ... 6e 73 74 75 63 6b 20 67 Fatal Python error: bad trailing pad byte
That appears to be the "it u" near the end of the desired output (from "git und"). So this isn't just off by 1, it's overwriting by a lot. That may be a pymalloc bug, but the odds don't favor it.
- Previous message: [Python-Dev] Regression in unicodestr.encode()?
- Next message: [Python-Dev] Regression in unicodestr.encode()?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]