in reply to Re^3: [OT] Stats problem
in thread [OT] Stats problem
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.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^5: [OT] Stats problem
by roboticus (Chancellor) on Feb 27, 2015 at 16:52 UTC |