Re^3: [OT] Stats problem

BrowserUk:

For that particular use case, you might try something I did when I had a similar problem: Put a matching marker just *before* the address you return in your malloc routine. (In mine, I had a counter inside of malloc, so the marker just happened to be the number of times malloc was called (plus the starting value). I bracketed the requested memory area with the marker, and filled the block with junk. I added the 'before' marker because I was tracking down a buffer overrun as well. (Another thing I did was to put the caller's address and the requested allocation size in the preamble as a debugging aid. Fit nicely in a 'paragraph' in 32-bit mode.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

Comment on Re^3: [OT] Stats problem

Replies are listed 'Best First'.
Re^4: [OT] Stats problem by BrowserUk (Patriarch) on Feb 27, 2015 at 12:23 UTC
That would certainly be advantageous in that it would allow you to definitively detect which address the overrun had occurred through. The downside is that it adds another 4 bytes to the overhead for every allocation. Probably not a problem for a debug malloc library -- although one of the problems I had was that when I enabled the debug malloc, the program which was designed to run close to the limits of my physical memory without going into swapping, moved into swapping and ran like it was swimming n molasses as a result. So much so that I had to modify the parameters to reduce the memory usage to 1/4 to avoid swapping; which in turn meant that the problem I was trying to track down never actually occured. The real advantage of the method I described is that it uses no extra space in actual allocation as it is only written to free space slots. Either when the virtual memory is first obtained; or when a pointer is freed. Of course, it will then only detect overruns if the happen to encounter a free slot; but with the advantage that they can remain enabled, at very little overhead, in production code. I also had the notion of using two interleaving, free space chains. The first would be used, leaving (at least one) free space between all allocations, until it filled. Only then would the second be used. That might afford early(er) and more accurate detection of overruns. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". I'm with torvalds on this In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked	[reply]
Re^5: [OT] Stats problem by roboticus (Chancellor) on Feb 27, 2015 at 16:52 UTC
BrowserUk: Yeah, it can consume more memory. I always had a paragraph at the beginning, but the marker at the end was "free" roughly 1/4 of the time, since the allocator had to round up to the next paragraph anyway (MSVC 6.0, I don't know if it has the same strategy/constraints in newer versions). I really like the idea of two interleaved free chains to aid in detection. I noticed that in the applications I worked on, that allocation usually happened in just a few particular sizes, so allocating two blocks at a time (both of the same size) and dropping the second one into a free list might be interesting. I'll have to remember this when I do my next fun C/++ job. ...roboticus When your only tool is a hammer, all problems look like your thumb.	[reply]