2

When using valgrind there is a section for a still reachable leak, but this should eventually be cleaned up by the OS. Is there ever a case where this will be an issue? I was thinking cases with threading possibly where the OS would not clean up the still reachable leak in a child process until the main process has completed, but I am not sure if this is a possible case either.

Essentially is there ever an issue with not freeing memory that is used until the end of execution (program exit)?

zimooo2
  • 421
  • 1
  • 4
  • 9
  • 5
    Does this address your concern? https://stackoverflow.com/questions/3840582/still-reachable-leak-detected-by-valgrind – StoryTeller - Unslander Monica Apr 15 '19 at 05:18
  • 1
    I thought it is called "memory leak" because memory isn't reachable anymore. ;-) Reading StoryTeller's link, I realized there seems to be not as clear definition as I expected. I'm with the "definition" in Wikipedia: [Memory Leak](https://en.wikipedia.org/wiki/Memory_leak) _A memory leak may also happen when an object is stored in memory but cannot be accessed by the running code._ – Scheff's Cat Apr 15 '19 at 05:34
  • Still reachable memory is usually not as serious as leaked memory. However, it is a problem if the still reachable memory will never be used again and its presence means that the program suffers a memory allocation failure that would not have occurred had some or all of the still reachable memory been freed. – Jonathan Leffler Apr 15 '19 at 06:18
  • @StoryTeller I don't think this does at it implies that there could be issues but doesn't list them – zimooo2 Apr 15 '19 at 06:19
  • @JonathanLeffler I am implying that memory is not cleaning up at the end of execution, but it is used until then. – zimooo2 Apr 15 '19 at 06:19
  • 2
    When a process exits the OS cleans up after it; reclaiming memory, closing open files, etc. There's no real reason to free everything manually. – Shawn Apr 15 '19 at 06:40
  • There is no guarantee that the OS will free all allocated memory on process termination. For example Windows sockets are sometimes leaked forever when not closed properly. There might also be an OS which does no cleanup at all. So it's platform-defined. – rustyx Apr 15 '19 at 07:15
  • 1
    @Shawn: Apparently, my workstation has been running for 326 days now. That means a bunch of processes (cron, the GUI, Apache, FTP server, DHCP server, IRC client, ...) have been running for 326 days. None of these things should ever terminate. They must not leak memory. I do not have an infinite amount of swap space they can waste. – Brendan Apr 15 '19 at 07:46
  • 1
    @Brendan and if those programs include some dynamic allocation that they acquired once at the start and hold onto until process exit, but *could* choose to release earlier, they aren't leaking memory. – Caleth Apr 15 '19 at 09:24
  • 1
    @Brendan That has nothing to do with not needing to go out of the way to free all allocated memory at program exit? I'm not saying to *never* bother to free memory when it's not needed any more... – Shawn Apr 15 '19 at 10:04
  • 1
    @Shawn: Who said anything about "at program exit" (and why are you falsely assuming that all processes exit eventually)? – Brendan Apr 15 '19 at 10:06
  • 1
    @Brendan I did, plus that's what the question is about. Valgrind's 'still reachable' count is memory that's been allocated that the program can still see at exit. Freeing up memory during a program's run after it's no longer needed is good, but, once again, no need to go out of the way to do so when it exits. – Shawn Apr 15 '19 at 10:09
  • @Shawn: Ah - I understand now. You're confusing "during testing before release" with "actual use after release". Obviously (when testing a process that might not terminate and/or may run for a very long time) the developer will run it for a very short time in valgrind; and if valgrid says memory is still reachable they'll realize it could indicate a huge problem for normal usage (outside of "brief period of testing"). – Brendan Apr 15 '19 at 10:31

1 Answers1

2

Sure. Say the program you are running under Valgrind is a test case for some remote request handler. In production, a server will handle many, many requests; probability only limited by the total system uptime. So each request must clean up its garbage.

A few test cases aren't going to simulate the lifetime memory use of the server, but they are sufficient to test the hypothesis that no request leaves garbage behind. If garbage is left behind, it's a bug whether or not it happens that there is still a pointer to the garbage or not. And Valgrind can help you figure that out.

rici
  • 234,347
  • 28
  • 237
  • 341
  • Isnt this memory still cleaned up though when the process ends by the OS? – zimooo2 Apr 15 '19 at 23:41
  • @zimooo2: sure, but the process may never actually end. If it is a web server, and a little memory is used by each request and never recovered, then the server will eventually choke. Even if all the allocations are still reachable. (Classic example: they're in a map or linked list, but will never be reused.) – rici Apr 16 '19 at 00:12