I used the tracking allocator example provided in the overview to check that I didn't have any leaks, after patching up my code I noticed that valgrind was still reporting a single un-freed allocation and after much frustration I discovered that it was in the snippet that I yoinked from the docs that was causing it lol.
Command: valgrind --leak-check=full ./a.out
Before
```
==28155== HEAP SUMMARY:
==28155== in use at exit: 9,607 bytes in 1 blocks
==28155== total heap usage: 10 allocs, 9 frees, 26,646 bytes allocated
==28155==
==28155== 9,607 bytes in 1 blocks are definitely lost in loss record 1 of 1
==28155== at 0x4842794: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==28155== by 0x43D842: os.heap_alloc (os_linux.odin:865)
==28155== by 0x43EF6C: os.heap_allocator_proc.aligned_alloc-0 (os.odin:190)
==28155== by 0x40B4DB: os.heap_allocator_proc (os.odin:230)
==28155== by 0x40BBEE: runtime.mem_alloc_non_zeroed (internal.odin:152)
==28155== by 0x411E05: runtime.map_alloc_dynamic (dynamic_map_internal.odin:372)
==28155== by 0x412F1B: runtime.map_reserve_dynamic (dynamic_map_internal.odin:545)
==28155== by 0x412D07: runtime.map_grow_dynamic (dynamic_map_internal.odin:513)
==28155== by 0x4168F2: runtime.__dynamic_map_check_grow (dynamic_map_internal.odin:827)
==28155== by 0x416A5F: runtime.__dynamic_map_set (dynamic_map_internal.odin:845)
==28155== by 0x41F7BD: mem.tracking_allocator_proc (allocators.odin:944)
==28155== by 0x40BBEE: runtime.mem_alloc_non_zeroed (internal.odin:152)
==28155==
==28155== LEAK SUMMARY:
==28155== definitely lost: 9,607 bytes in 1 blocks
==28155== indirectly lost: 0 bytes in 0 blocks
==28155== possibly lost: 0 bytes in 0 blocks
==28155== still reachable: 0 bytes in 0 blocks
==28155== suppressed: 0 bytes in 0 blocks
```
After
```
==32343== HEAP SUMMARY:
==32343== in use at exit: 0 bytes in 0 blocks
==32343== total heap usage: 10 allocs, 10 frees, 26,646 bytes allocated
==32343==
==32343== All heap blocks were freed -- no leaks are possible
```
Kelimion
commented
1 year ago
I used the tracking allocator example provided in the overview to check that I didn't have any leaks, after patching up my code I noticed that valgrind was still reporting a single un-freed allocation and after much frustration I discovered that it was in the snippet that I yoinked from the docs that was causing it lol.
Command:
valgrind --leak-check=full ./a.outBefore
``` ==28155== HEAP SUMMARY: ==28155== in use at exit: 9,607 bytes in 1 blocks ==28155== total heap usage: 10 allocs, 9 frees, 26,646 bytes allocated ==28155== ==28155== 9,607 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==28155== at 0x4842794: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==28155== by 0x43D842: os.heap_alloc (os_linux.odin:865) ==28155== by 0x43EF6C: os.heap_allocator_proc.aligned_alloc-0 (os.odin:190) ==28155== by 0x40B4DB: os.heap_allocator_proc (os.odin:230) ==28155== by 0x40BBEE: runtime.mem_alloc_non_zeroed (internal.odin:152) ==28155== by 0x411E05: runtime.map_alloc_dynamic (dynamic_map_internal.odin:372) ==28155== by 0x412F1B: runtime.map_reserve_dynamic (dynamic_map_internal.odin:545) ==28155== by 0x412D07: runtime.map_grow_dynamic (dynamic_map_internal.odin:513) ==28155== by 0x4168F2: runtime.__dynamic_map_check_grow (dynamic_map_internal.odin:827) ==28155== by 0x416A5F: runtime.__dynamic_map_set (dynamic_map_internal.odin:845) ==28155== by 0x41F7BD: mem.tracking_allocator_proc (allocators.odin:944) ==28155== by 0x40BBEE: runtime.mem_alloc_non_zeroed (internal.odin:152) ==28155== ==28155== LEAK SUMMARY: ==28155== definitely lost: 9,607 bytes in 1 blocks ==28155== indirectly lost: 0 bytes in 0 blocks ==28155== possibly lost: 0 bytes in 0 blocks ==28155== still reachable: 0 bytes in 0 blocks ==28155== suppressed: 0 bytes in 0 blocks ```After
``` ==32343== HEAP SUMMARY: ==32343== in use at exit: 0 bytes in 0 blocks ==32343== total heap usage: 10 allocs, 10 frees, 26,646 bytes allocated ==32343== ==32343== All heap blocks were freed -- no leaks are possible ```