Tim Peters <tim.one@comcast.net> writes:
> [Michael Hudson]
> > ...
> > Presuambly it would be possible to do this wrapped around malloc() &
> > free() too?
>
> Provided they were spelled PyMem_Malloc etc, sure. The debug routines as
> sketched don't make any secret assumptions about the underlying allocators
> they call.
That's what I thought.
> > No real point, I guess.
>
> There may be an excellent point to it: one of the pad bytes could be used
> to record which "API family" a block of memory came from. Then a
> mismatching realloc/free could be caught directly at the time it happened.
Good point!
> >> + The Debug free first uses the address to find the number of bytes
> >> originally asked for, then checks the 8 bytes on each end for
> >> sanity (in particular, that the PYMALLOC_FORBIDDENBYTEs are still
> >> intact).
> >> XXX Make this checking a distinct entry point.
>
> > Yes. Particularly if you can call it from gdb.
>
> Is something extraordinary required to make that possible? I had in mind
> nothing fancier than
>
> extern void _PyMalloc_DebugCheckAddress(void* p);
Dunno. I ought to learn how to use gdb properly.
[...]
> > ...
> > What are you waiting for? <wink>
>
> For endless silly objections to fade away <wink>.
Well, if you consider my comments to be objections, feel free to
consider them to be written in very faint writing :)
Cheers,
M.
--
While preceding your entrance with a grenade is a good tactic in
Quake, it can lead to problems if attempted at work. -- C Hacking
-- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html
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