Closed tkomatsu closed 3 years ago
still reachableって前回提出の時もあるまま提出したんだっけ? 前回もあるなら放置するけど、前回は処理をしたのであれば改変箇所で起こっているので、その辺りの修正を加える必要がありそう。
still reachable はあるまま提出してる! このメモリリーク前回のfix_tokenの修正のせいっぽいな、、 newのfreeし忘れかな。
1 bytes in 1 blocks are definitely lost in loss record 1 of 58
↑の原因は、前回のfix_tokenで空文字列のnewをfreeしないままreturn返しているため。
2,048 bytes in 1 blocks are definitely lost in loss record 56 of 58
↑これの原因がよくわからない、、
メモリリーク増えた、、?
おそらく私の勘違いでした。。
現時点のmainブランチで確認。 ※ expand_tokenのメモリリークはfix_leakにpush済みの修正で解消済み。
==61404== HEAP SUMMARY:
==61404== in use at exit: 18,394 bytes in 215 blocks
==61404== total heap usage: 1,298 allocs, 1,083 frees, 248,554 bytes allocated
==61404==
==61404== 1 bytes in 1 blocks are definitely lost in loss record 1 of 57
==61404== at 0x100128D04: malloc (vg_replace_malloc.c:310)
==61404== by 0x10000AF6C: ft_strjoin (in ./minishell)
==61404== by 0x1000060DF: strjoin_free (expand_tokens.c:25)
==61404== by 0x100006056: expand_token (expand_tokens.c:51)
==61404== by 0x100005EE5: expand_tokens (expand_tokens.c:71)
==61404== by 0x100009F32: ft_lstiter (in ./minishell)
==61404== by 0x1000067FE: parse_exec (parse_exec.c:66)
==61404== by 0x100004396: minish_loop (minishell.c:101)
==61404== by 0x100004107: main (minishell.c:111)
==61404==
==61404== 259 bytes in 1 blocks are definitely lost in loss record 43 of 57
==61404== at 0x100128D04: malloc (vg_replace_malloc.c:310)
==61404== by 0x10000AE53: ft_strdup (in ./minishell)
==61404== by 0x10000502D: output (get_next_input.c:63)
==61404== by 0x100004CF3: get_next_input (get_next_input.c:105)
==61404== by 0x1000044D4: read_stdin (read_stdin.c:76)
==61404== by 0x100004344: minish_loop (minishell.c:93)
==61404== by 0x100004107: main (minishell.c:111)
==61404==
==61404== 1,872 (320 direct, 1,552 indirect) bytes in 1 blocks are definitely lost in loss record 54 of 57
==61404== at 0x100128D04: malloc (vg_replace_malloc.c:310)
==61404== by 0x10000A5D6: ft_calloc (in ./minishell)
==61404== by 0x100008AC5: reset (ft_setenv.c:44)
==61404== by 0x100008A30: ft_setenv (ft_setenv.c:87)
==61404== by 0x100008920: ft_putenv (ft_putenv.c:31)
==61404== by 0x100007A2A: ft_export (ft_export.c:82)
==61404== by 0x10000708D: execmd (execmd.c:26)
==61404== by 0x100006AB1: run_cmd (run_cmd.c:27)
==61404== by 0x100006831: parse_exec (parse_exec.c:68)
==61404== by 0x100004396: minish_loop (minishell.c:101)
==61404== by 0x100004107: main (minishell.c:111)
==61404==
==61404== 2,048 bytes in 1 blocks are definitely lost in loss record 55 of 57
==61404== at 0x100128D04: malloc (vg_replace_malloc.c:310)
==61404== by 0x100709E95: class_setWeakIvarLayout (in /usr/lib/libobjc.A.dylib)
==61404== by 0x100709E26: class_setWeakIvarLayout (in /usr/lib/libobjc.A.dylib)
==61404== by 0x10070DBF9: _objc_atfork_parent (in /usr/lib/libobjc.A.dylib)
==61404== by 0x1006FB742: property_copyAttributeList (in /usr/lib/libobjc.A.dylib)
==61404== by 0x1006F11E7: NXMapRemove (in /usr/lib/libobjc.A.dylib)
==61404== by 0x100703BD2: attachCategories(objc_class*, locstamped_category_t const*, unsigned int, int) (in /usr/lib/libobjc.A.dylib)
==61404== by 0x1007036C6: objc_class::mangledName() (in /usr/lib/libobjc.A.dylib)
==61404== by 0x10070369F: objc_class::mangledName() (in /usr/lib/libobjc.A.dylib)
==61404== by 0x10070369F: objc_class::mangledName() (in /usr/lib/libobjc.A.dylib)
==61404== by 0x10070369F: objc_class::mangledName() (in /usr/lib/libobjc.A.dylib)
==61404== by 0x1006EF406: objc_opt::objc_stringhash_t::getIndex(char const*) const (in /usr/lib/libobjc.A.dylib)
==61404==
==61404== LEAK SUMMARY:
==61404== definitely lost: 2,628 bytes in 4 blocks
==61404== indirectly lost: 1,552 bytes in 39 blocks
==61404== possibly lost: 0 bytes in 0 blocks
==61404== still reachable: 2,526 bytes in 15 blocks
==61404== suppressed: 11,688 bytes in 157 blocks
==61404== Reachable blocks (those to which a pointer was found) are not shown.
==61404== To see them, rerun with: --leak-check=full --show-leak-kinds=all
よくわからないのですが、minishellのディレクトリを削除して再度git cloneし直してvalgrindかけたら片方のメモリリークが検出されなくなりました。
==83017== HEAP SUMMARY:
==83017== in use at exit: 13,802 bytes in 161 blocks
==83017== total heap usage: 1,898 allocs, 1,737 frees, 308,890 bytes allocated
==83017==
==83017== 1 bytes in 1 blocks are definitely lost in loss record 2 of 37
==83017== at 0x100128D04: malloc (vg_replace_malloc.c:310)
==83017== by 0x10000AF6C: ft_strjoin (in ./minishell)
==83017== by 0x1000060DF: strjoin_free (expand_tokens.c:25)
==83017== by 0x100006056: expand_token (expand_tokens.c:51)
==83017== by 0x100005EE5: expand_tokens (expand_tokens.c:71)
==83017== by 0x100009F32: ft_lstiter (in ./minishell)
==83017== by 0x1000067FE: parse_exec (parse_exec.c:66)
==83017== by 0x100004396: minish_loop (minishell.c:101)
==83017== by 0x100004107: main (minishell.c:111)
==83017==
==83017== LEAK SUMMARY:
==83017== definitely lost: 1 bytes in 1 blocks
==83017== indirectly lost: 0 bytes in 0 blocks
==83017== possibly lost: 0 bytes in 0 blocks
==83017== still reachable: 1 bytes in 1 blocks
==83017== suppressed: 13,800 bytes in 159 blocks
==83017== Reachable blocks (those to which a pointer was found) are not shown.
==83017== To see them, rerun with: --leak-check=full --show-leak-kinds=all
確かにクローンしなおしたらリークしてないですね 🤔
https://stackoverflow.com/questions/64445627/valgrind-strange-memory-leak 調べてみたら似たような現象に当たった人がいるみたい。
valgrindのバグかな
何回かクローンしなおしても出てこないのでバグということにしましょう!