Valgrind mark deliberate leak

Question

I feel like this has to be a feature, but my Google-Fu has failed me. I apologize in advance if this has been asked/answered before, it feels so obvious, but I couldn't find anything.

Is there a means to mark an allocation as deliberately leaking? The context is a data structure that is dynamically allocated once during program init and used throughout the program lifetime. There's no real reason to free all of the allocated objects just before program termination (why clean up the room when there's a wrecking ball headed for the whole house?), but it results in a lot of false-positives from valgrind.

I am aware that I could create a suppression file, but that feels manual and disconnected. I would much prefer some kind of macro or other in-source annotation that this allocation is intentionally never freed (e.g. something akin to malloc(...) -> malloc_IGNORE_LEAK(...)). Does valgrind support this in some way?

If it doesn't, what it the preferred solution for marking / tracking deliberate "leaks"?

This answer to a question regarding memory being freed at the end of execution sums on my thoughts on it: http://stackoverflow.com/a/2213644/1609219 — Macattack, Jul 25 '13 at 20:56
I am of the opposite ideology in this case. The application in question isn't at all cross-platform (nor is it trying to be), it is designed to run in a Unix environment on a relatively high-powered machine. In a modern context, this means virtual memory. Indeed, the following answer by Kevin is extremely appropriate in this case. This question was not "should I free program-lifetime memory", it was "I intend to let the OS do its job, how do I tell that to other tools" — Pat, Jul 25 '13 at 21:17
I understood your question, that's why I didn't post as an answer, only a comment. That being said, are they still reachable? Or, could you store pointers to everything allocated and that way keeping the memory reachable, and making `--show-reachable=no` feasible. — Macattack, Jul 25 '13 at 21:34
it's really hard to avoid leaking while using `malloc`, `malloc` is basically unsafe by definition. — user2485710, Jul 26 '13 at 01:03

score 0 · Answer 1 · answered Jul 25 '13 at 22:32

The code below makes use of a few globals and a wrapper on malloc(). You could use it for any malloc calls which you're not worried about leaking memory from. Anything malloced using my_malloc() will show up under still reachable leaks since you'll still have a reference to it.

void ** memorys = NULL;
size_t max_index = 0;
size_t use_index = 0;

void grow_memorys() {
    if (memorys == NULL) {
        max_index = 8;
        memorys = malloc(max_index * sizeof(void *));
    }
    else { 
        max_index *= 2;
        memorys = realloc(memorys, max_index * sizeof(void *));
    }
}   

void * my_malloc(size_t size) {
    void * point = malloc(size);
    if (use_index >= max_index) {
        grow_memorys();
    }
    memorys[use_index] = point;
    use_index++;
    return point;
}

Using show-reachable in this way changes to problem from false positives to false negatives however. It is possible that there are blocks that are still reachable that should have been freed. This is only useful in the case that I freed everything I intended to, which is what I'm setting out to prove in the first place. It would work if I could instruct valgrind "ignore everything reachable from `memorys`", but if that existed I could simply apply it to the initial allocations and be done with it. — Pat, Jul 25 '13 at 23:30

score 0 · Answer 2 · answered Jul 25 '13 at 23:12

0

You could make your own malloc wrapper which registers 'permanent' allocations for an atexit handler to free. However this may be unsafe in a multithreaded program if other threads could be using them still.

answered Jul 25 '13 at 23:12

R.. GitHub STOP HELPING ICE

208,859
35
376
711

You're missing the spirit of the question. The goal is *not* to free the memory, simply to express to tools (valgrind et al) that I am "leaking" the memory on purpose as there would be no point in freeing it---indeed there may actually be negative consequences. – Pat Jul 25 '13 at 23:32
I was just saying that "freeing the memory at the last minute, in a way that's non-invasive to the program design and easy to turn off when you're not using valgrind" would be one way to quiet the leak report. – R.. GitHub STOP HELPING ICE Jul 26 '13 at 00:51
Ah, a better point. Yes, I suppose that would be a solution, but it would require something akin to Macattack's allocation tracker as this program is heavily multithreaded. At some point there's the tradeoff of how much time / effort / code should be put into a leak-tracking debugger :/ – Pat Jul 26 '13 at 22:33

Valgrind mark deliberate leak

2 Answers2