Should we ignore "still reachable" memory and/or handle interrupts?

Hello,

I have the following problem. When I run the task debugMemoryQuantum and use ctrl + c upon being asked for input I get this:

 Executing task: bash -c 'valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes ./bin/wordle_opt 5 data/5.txt y' <

==4162== Memcheck, a memory error detector
==4162== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==4162== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==4162== Command: ./bin/wordle_opt 5 data/5.txt y
==4162== 
The selected word is "umpty". (Do not tell anyone)
The selected dual word is "decor". (Do not tell anyone)
Please input your guess: ^C==4162== 
==4162== Process terminating with default action of signal 2 (SIGINT)
==4162==    at 0x49731B2: read (in /usr/lib/libc.so.6)
==4162==    by 0x48F72B3: _IO_file_underflow@@GLIBC_2.2.5 (in /usr/lib/libc.so.6)
==4162==    by 0x48EBA57: getdelim (in /usr/lib/libc.so.6)
==4162==    by 0x10A517: guess (in /home/prog2/Documents/project3/bin/wordle_opt)
==4162==    by 0x109249: main (in /home/prog2/Documents/project3/bin/wordle_opt)
==4162== 
==4162== HEAP SUMMARY:
==4162==     in use at exit: 5,352,716 bytes in 24,776 blocks
==4162==   total heap usage: 34,353 allocs, 9,577 frees, 7,429,202 bytes allocated
==4162== 
==4162== 6 bytes in 1 blocks are still reachable in loss record 1 of 7
==4162==    at 0x4845899: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4162==    by 0x1091EE: main (in /home/prog2/Documents/project3/bin/wordle_opt)
==4162== 
==4162== 6 bytes in 1 blocks are still reachable in loss record 2 of 7
==4162==    at 0x4845899: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4162==    by 0x1091F9: main (in /home/prog2/Documents/project3/bin/wordle_opt)
==4162== 
==4162== 120 bytes in 1 blocks are still reachable in loss record 3 of 7
==4162==    at 0x4845899: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4162==    by 0x48EB873: getdelim (in /usr/lib/libc.so.6)
==4162==    by 0x10A517: guess (in /home/prog2/Documents/project3/bin/wordle_opt)
==4162==    by 0x109249: main (in /home/prog2/Documents/project3/bin/wordle_opt)
==4162== 
==4162== 216 bytes in 1 blocks are still reachable in loss record 4 of 7
==4162==    at 0x4845899: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4162==    by 0x10A289: readDictFromFile (in /home/prog2/Documents/project3/bin/wordle_opt)
==4162==    by 0x10A3E0: generateDict (in /home/prog2/Documents/project3/bin/wordle_opt)
==4162==    by 0x10920C: main (in /home/prog2/Documents/project3/bin/wordle_opt)
==4162== 
==4162== 1,024 bytes in 1 blocks are still reachable in loss record 5 of 7
==4162==    at 0x4845899: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4162==    by 0x48EA470: _IO_file_doallocate (in /usr/lib/libc.so.6)
==4162==    by 0x48F823F: _IO_doallocbuf (in /usr/lib/libc.so.6)
==4162==    by 0x48F75D7: _IO_file_overflow@@GLIBC_2.2.5 (in /usr/lib/libc.so.6)
==4162==    by 0x48F66B5: _IO_file_xsputn@@GLIBC_2.2.5 (in /usr/lib/libc.so.6)
==4162==    by 0x48E158D: __vfprintf_internal (in /usr/lib/libc.so.6)
==4162==    by 0x48CE86E: printf (in /usr/lib/libc.so.6)
==4162==    by 0x109220: main (in /home/prog2/Documents/project3/bin/wordle_opt)
==4162== 
==4162== 1,024 bytes in 1 blocks are still reachable in loss record 6 of 7
==4162==    at 0x4845899: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4162==    by 0x48EA470: _IO_file_doallocate (in /usr/lib/libc.so.6)
==4162==    by 0x48F823F: _IO_doallocbuf (in /usr/lib/libc.so.6)
==4162==    by 0x48F735C: _IO_file_underflow@@GLIBC_2.2.5 (in /usr/lib/libc.so.6)
==4162==    by 0x48EBA57: getdelim (in /usr/lib/libc.so.6)
==4162==    by 0x10A517: guess (in /home/prog2/Documents/project3/bin/wordle_opt)
==4162==    by 0x109249: main (in /home/prog2/Documents/project3/bin/wordle_opt)
==4162== 
==4162== 5,350,320 bytes in 24,770 blocks are still reachable in loss record 7 of 7
==4162==    at 0x4845899: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4162==    by 0x109D69: insert (in /home/prog2/Documents/project3/bin/wordle_opt)
==4162==    by 0x10A335: readDictFromFile (in /home/prog2/Documents/project3/bin/wordle_opt)
==4162==    by 0x10A3E0: generateDict (in /home/prog2/Documents/project3/bin/wordle_opt)
==4162==    by 0x10920C: main (in /home/prog2/Documents/project3/bin/wordle_opt)
==4162== 
==4162== LEAK SUMMARY:
==4162==    definitely lost: 0 bytes in 0 blocks
==4162==    indirectly lost: 0 bytes in 0 blocks
==4162==      possibly lost: 0 bytes in 0 blocks
==4162==    still reachable: 5,352,716 bytes in 24,776 blocks
==4162==         suppressed: 0 bytes in 0 blocks
==4162== 
==4162== For lists of detected and suppressed errors, rerun with: -s
==4162== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

and the same is not the case if I run the same task and immediately input the correct word. (And I did not receive any errors during normal play ending in a win)

The valgrind documentation has this to say about “still reachable” memory:

"Still reachable". [...] Since the block is still pointed at, the programmer could, at least in principle, have freed it before program exit. "Still reachable" blocks are very common and arguably not a problem. [...]

I did a bit of research and the way to handle this seems to involve catching a signal (the SIGINT from the above report) sent to my program from pressing ctrl + c. The way to do that in turn is to invoke this monstrosity.

At this point it seems much too complicated to be expected of us, so … we just accept that this happens because the memory will be freed by the OS anyway? (But then we could just remove all the calls to free at the end of main)

No (or Yes… depending on which version of the question I’m responding to).

You can assume that no signals are delivered to your program. If there are, the default action happens, which is either ignoring or terminating the program (in some fashion). Either way, in case of such a non-standard termination, you usually do not care about freeing resources since they will get freed anyway.

Valgrint still complaints, because you want it to show resource leaks in programs where you do care about behavior on signals, but wordle is not one of those.

1 Like