riff
riff copied to clipboard
riff-lang
Memory leaks
I happened to come cross your repo and built it with our SaiphC. The following is an incomplete list of memory blocks that are not freed at the exit of riff. It's not a big deal as the system will reclaim at the exit. just FYI.
The following is a partial list. Here is the complete list: https://raw.githubusercontent.com/cee-studio/anything/main/riff.log
# a memory block (start:0xa5483c0, size:16 bytes) is allocated at
# /tmp/riff/src/val.c:31, 17
# /tmp/riff/src/vm.c:964, 18
# /tmp/riff/src/vm.c:469, 12
# /tmp/riff/src/riff.c:108, 9
# [libc-start-main]
# a memory block (start:0xa5483f0, size:28 bytes) is allocated at
# /tmp/riff/src/val.c:32, 17
# /tmp/riff/src/vm.c:964, 18
# /tmp/riff/src/vm.c:469, 12
# /tmp/riff/src/riff.c:108, 9
# [libc-start-main]
# a memory block (start:0xa548430, size:16 bytes) is allocated at
# /tmp/riff/src/val.c:5, 17
# /tmp/riff/src/table.c:22, 16
# /tmp/riff/src/val.c:33, 5
# /tmp/riff/src/vm.c:964, 18
# /tmp/riff/src/vm.c:469, 12
# /tmp/riff/src/riff.c:108, 9
# [libc-start-main]
# a memory block (start:0xa548460, size:20 bytes) is allocated at
# /tmp/riff/src/table.c:24, 16
# /tmp/riff/src/val.c:33, 5
# /tmp/riff/src/vm.c:964, 18
# /tmp/riff/src/vm.c:469, 12
# /tmp/riff/src/riff.c:108, 9
# [libc-start-main]
# a memory block (start:0xa548490, size:24 bytes) is allocated at
# /tmp/riff/src/table.c:186, 20
# /tmp/riff/src/vm.c:964, 18
# /tmp/riff/src/vm.c:469, 12
# /tmp/riff/src/riff.c:108, 9
# [libc-start-main]
# a memory block (start:0xa5484d0, size:16 bytes) is allocated at
# /tmp/riff/src/table.c:200, 26
# /tmp/riff/src/vm.c:964, 18
# /tmp/riff/src/vm.c:469, 12
# /tmp/riff/src/riff.c:108, 9
# [libc-start-main]
# a memory block (start:0xa548500, size:16 bytes) is allocated at
# /tmp/riff/src/table.c:200, 26
# /tmp/riff/src/vm.c:964, 18
# /tmp/riff/src/vm.c:469, 12
# /tmp/riff/src/riff.c:108, 9
# [libc-start-main]
# a memory block (start:0xa548530, size:16 bytes) is allocated at
# /tmp/riff/src/table.c:200, 26
# /tmp/riff/src/vm.c:964, 18
# /tmp/riff/src/vm.c:469, 12
# /tmp/riff/src/riff.c:108, 9
# [libc-start-main]
# a memory block (start:0xa548560, size:16 bytes) is allocated at
# /tmp/riff/src/table.c:200, 26
# /tmp/riff/src/vm.c:964, 18
# /tmp/riff/src/vm.c:469, 12
# /tmp/riff/src/riff.c:108, 9
# [libc-start-main]
# a memory block (start:0xa548590, size:16 bytes) is allocated at
# /tmp/riff/src/table.c:200, 26
# /tmp/riff/src/vm.c:964, 18
# /tmp/riff/src/vm.c:469, 12
# /tmp/riff/src/riff.c:108, 9
# [libc-start-main]
# a memory block (start:0xa5485c0, size:16 bytes) is allocated at
# /tmp/riff/src/table.c:200, 26
# /tmp/riff/src/vm.c:964, 18
# /tmp/riff/src/vm.c:469, 12
# /tmp/riff/src/riff.c:108, 9
# [libc-start-main]
https://cee.studio/explanation
Thanks for the issue. I'm aware of the egregious memory leaks. Many of these are simple fixes (e.g. the program being read into memory). I've just been too focused on getting language features working and haven't gotten around to cleaning up the allocations.
I'm inferring based on the size of the second leak in your log (805 bytes), you ran riff with ex/array.rf, correct?
I don't know if this would be useful for your own project, but I like using Clang's LeakSanitizer for identifying leaks. Here's the partial output running the same program:
=================================================================
==62231==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 805 byte(s) in 1 object(s) allocated from:
#0 0x1088ffb88 in wrap_malloc+0x58 (libclang_rt.lsan_osx_dynamic.dylib:x86_64h+0x9b88)
#1 0x1088391c5 in u_file2str util.c:17
#2 0x108826a45 in main riff.c:95
#3 0x7fff205bbf5c in start+0x0 (libdyld.dylib:x86_64+0x15f5c)
Direct leak of 768 byte(s) in 6 object(s) allocated from:
#0 0x1088ffcdd in wrap_realloc+0x5d (libclang_rt.lsan_osx_dynamic.dylib:x86_64h+0x9cdd)
#1 0x10883738e in add_local parse.c:637
#2 0x108836f40 in anon_fn parse.c:282
#3 0x1088360c1 in nud parse.c:403
#4 0x1088359c7 in expr parse.c:483
#5 0x108837189 in expr_list parse.c:226
#6 0x108836a29 in table parse.c:262
#7 0x108835f40 in nud parse.c:372
#8 0x1088359c7 in expr parse.c:483
#9 0x108836935 in led parse.c:474
#10 0x108835a9c in expr parse.c:507
#11 0x108837189 in expr_list parse.c:226
#12 0x108834b86 in expr_stmt parse.c:515
#13 0x10883443d in stmt parse.c:1057
#14 0x1088340c2 in stmt_list parse.c:1067
#15 0x108833f33 in y_compile parse.c:1096
#16 0x108826aa4 in main riff.c:102
#17 0x7fff205bbf5c in start+0x0 (libdyld.dylib:x86_64+0x15f5c)
...
Indirect leak of 2 byte(s) in 1 object(s) allocated from:
#0 0x1088ffb88 in wrap_malloc+0x58 (libclang_rt.lsan_osx_dynamic.dylib:x86_64h+0x9b88)
#1 0x108837d63 in s_newstr str.c:11
#2 0x108827af1 in c_global code.c:290
#3 0x108836db8 in identifier parse.c:168
#4 0x1088360a6 in nud parse.c:399
#5 0x1088359c7 in expr parse.c:483
#6 0x108837189 in expr_list parse.c:226
#7 0x108836a29 in table parse.c:262
#8 0x108835f40 in nud parse.c:372
#9 0x1088359c7 in expr parse.c:483
#10 0x108836935 in led parse.c:474
#11 0x108835a9c in expr parse.c:507
#12 0x108837189 in expr_list parse.c:226
#13 0x108834b86 in expr_stmt parse.c:515
#14 0x10883443d in stmt parse.c:1057
#15 0x1088340c2 in stmt_list parse.c:1067
#16 0x108833f33 in y_compile parse.c:1096
#17 0x108826aa4 in main riff.c:102
#18 0x7fff205bbf5c in start+0x0 (libdyld.dylib:x86_64+0x15f5c)
SUMMARY: LeakSanitizer: 3783 byte(s) leaked in 116 allocation(s).
I like the output since it groups objects with the same stack traces together and provides the total at the end.
Using this AWK program:
awk -F'[: ]' '/bytes/{leaks+=$10}END{print leaks}' riff.log
It seems your tool reports 8355 total bytes worth of leaks while LeakSanitizer only reports 3783 bytes. Unless I'm parsing the log file incorrectly, I'm definitely curious about the discrepancy.
Understood. I did the same for my code and only fix leaks after features are done.
Yes, I ran array.rf
Here is the aggregated report. Reporting the common stack trace will be a nice feature.
Unfreed memory warning: memory blocks are not freed before exit.
# 111 memory blocks are allocated at
# /tmp/riff/src/str.c:11, 17
# total 582 bytes are not freed.
#
# 7 memory blocks are allocated at
# /tmp/riff/src/code.c:23, 5
# total 360 bytes are not freed.
#
# 6 memory blocks are allocated at
# /tmp/riff/src/code.c:291, 5
# total 896 bytes are not freed.
#
# 1 memory block is allocated at
# /tmp/riff/src/util.c:17, 18
# total 805 bytes are not freed.
#
# 111 memory blocks are allocated at
# /tmp/riff/src/str.c:14, 17
# total 1332 bytes are not freed.
#
# 1 memory block is allocated at
# /musl-1.1.10/src/stdio/__fdopen.c:20, 10
# total 1164 bytes are not freed.
#
# 6 memory blocks are allocated at
# /tmp/riff/src/parse.c:272, 16
# total 72 bytes are not freed.
#
# ...
5211 bytes are leaked. Based on my experience, I haven't found any false negative or false positive in our report yet.