FYI, for anyone else looking at this. Guido tricked me into sending this to an internal PythonLabs address. -----Original Message----- From: Zope.Com Python Labs Sent: Saturday, October 06, 2001 12:47 AM To: Guido van Rossum Cc: Zope.Com Python Labs Subject: [PythonLabs] Re: [Python-Dev] RE: Painful death in debug build [Guido] > I tried efence on Linux (which traps bad stores using VM tricks) and > couldn't get it to fail either. Thanks for trying! I'll pursue here then. VM tricks may not be enough, unless they're very fine-grained. The MS debug malloc overallocates by 8 bytes, 4 on each side of the blocks it returns. These get filled with 0xFD bytes. When the debug free() gets a block back, it first checks these bytes. The four before the block are OK (still 0xFD). The first two bytes after the block have been zeroed, but the two bytes after those are still 0xFD. So who's storing 0 into a short via a computed address suffering an off-by-one error <0.9 wink>? (*) When I crank up enough energy, it should be more-or-less straightforward to set a data breakpoint on one of the byte addresses getting corrupted, and so catch the culprit in the act (the potential problem is that memory gets recycled, and on occasion I've had to give up on this approach after wading thru 100s of false alarms). (*) Hmm! Cogitating: the traceback pointed at a subclass of long, and the internal representation of longs is indeed one of the few places Python uses an array of shorts (Unicode is another -- others?). A dollar bets this will prove to be relevant.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4