@tiller said:
The original problem that malloc is fixing* is not a memory leak, but a stack overflow which is kinda the opposite of a memory leak(More data then allocated ram).
But this code does create a new leak :-}
*Fixing as in: Works for me now, don't touch anything.
The malloc fixes a buffer overflow by actually [i]creating[/i] a memory leak: that's what's funny/worrying about the comment.
Immediately before this the program declares a variable-sized array:
[code]float *some_array = malloc(sizeof(float) * (1 + magical_size_variable));[/code]
Running [code]malloc(4096);[/code] "works" because the new memory is allocated straight after the array. A more subtle and slightly less brittle way of doing the same stupid thing is to add 4096 to the malloc where the array is allocated, and a proper solution would be to fix whatever horrendous calculation is used to come up with the magical_size_variable.
I ended up not touching this code at all: it's executed once per page hit, so with a generous 1,000 hits per day = leaks 4MB per day. If I started fixing everything wrong with this code, I could keep going for years, and worse, I'd get a reputation as "the guy who knows about FooProject". Everything about this code is poison by now: the source control system before we inherited it was a bunch of folders named fooproject_1, fooproject_2 etc., up to fooproject_20.
Those numbers represent "branches", by the way, not revisions.