0

Leak Summary

1

I'm still new to valgrind and I don't have enough knowledge to evaluate this result. I was able to fix memory leaks in the past but the location of the leaks in my code were indicated, this time I have no idea how to fix a leak found in dl-init.c which is part of GNU C library.

vimuth
  • 5,064
  • 33
  • 79
  • 116
chuvz
  • 11
  • Remember that a leak "at exit" isn't really a problem (unless the leaked resource needs to do some essential cleanup). The OS kernel will release all memory on process exit. – Jesper Juhl Mar 22 '23 at 02:41
  • @JesperJuhl that may be true on an ideal computer with infinite memory. I work with process that are in the 10s to 100s of Gbytes. Not bothering to free memory would soon end with the Out Of Memory killer. In this case, glib being leaky is less of a problem as long as you use sure that they are one-off leaks. – Paul Floyd Mar 22 '23 at 16:18
  • @PaulFloyd I think you misunderstood my point. Of course you should free resources when you no longer need them, so the memory can be reused. But in the case where you dynamicaly allocate some memory and you need that memory all the way to normal program exit, then if the memory does not require special handling on freeing (like important destructors) then you can let your program shut down faster by just leaking the memory at exit and letting the OS clean it up - such "leaks" are *technically* leaks, but are not a problem. – Jesper Juhl Mar 24 '23 at 10:16
  • @JesperJuhl that's possible with care - such as maintaining a suppression file. My experience, though, is that projects that allow leaks generally accumulate them. – Paul Floyd Mar 24 '23 at 19:56

1 Answers1

0

reachable memory leaks are resources, that your program fetched from the system but did not return during its run - typically by using new().

These are no problem in case of an ensured quick exit (short runner programs) as all ressources are freed automatically upon exit(), but during a longer program run, they block memory, that you MAY have no use for anymore.

Most tend to fix ALL memory leaks for being sure to free up memory again. So care for freeing ALL ressources you aquired and your program is safe for long runs and your prof is happy also.

Only programs that definitely do not vary in run time/work amount can risk to not freeing such ressources. If you leave that, you'll regret it sooner or later for long running things (deamons or a large workload) only fetching ressources but nevert returning them explicitly. This will risk out-of-memory errors for really large tasks or for deamons/services etc.

Synopsis
  • 190
  • 10
  • I used to use Valgrind also, but switched to Sanitizer recently as it is much faster and its just there by GCC support – Synopsis Mar 22 '23 at 10:50
  • 1
    "Freeing all resources upon exit()" is **not** guaranteed. If you still hold allocated memory at program termination, that memory **is** leaked from a language perspective. Most desktop OS use memory protection and *can* recover such memory leaks for you. Others don't. What *is* guaranteed is that all *streams* are being closed on program termination. Memory, not so much. – DevSolar Mar 22 '23 at 10:55
  • sorry, yes, you're right :-) – Synopsis Mar 22 '23 at 11:55