Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

examples/vweb/test_app leaks memory for every request #1845

Open
jrmuizel opened this issue Sep 3, 2019 · 3 comments
Open

examples/vweb/test_app leaks memory for every request #1845

jrmuizel opened this issue Sep 3, 2019 · 3 comments
Labels

Comments

@jrmuizel
Copy link

@jrmuizel jrmuizel commented Sep 3, 2019

V version: 0.1.18
OS: Linux

Running examples/vweb/test_app and letting while true; do curl http://localhost:8082/text 2&>1 2> /dev/null; done run for a while produces a bunch of leaks:

==11296== 1,040,688 bytes in 19,272 blocks are definitely lost in loss record 638 of 647
==11296==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11296==    by 0x11DB00: _STR (test_app.tmp.c:8754)
==11296==    by 0x11B831: vweb__Context_text (test_app.tmp.c:8255)
==11296==    by 0x11D43B: App_text (test_app.tmp.c:8680)
==11296==    by 0x11C6D8: vweb__run_App (test_app.tmp.c:8458)
==11296==    by 0x11D339: main (test_app.tmp.c:8662)
==11296==
==11296== 1,079,456 bytes in 19,276 blocks are definitely lost in loss record 639 of 647
==11296==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11296==    by 0x11DB00: _STR (test_app.tmp.c:8754)
==11296==    by 0x112758: net__Socket_write (test_app.tmp.c:5708)
==11296==    by 0x11B84A: vweb__Context_text (test_app.tmp.c:8255)
==11296==    by 0x11D43B: App_text (test_app.tmp.c:8680)
==11296==    by 0x11C6D8: vweb__run_App (test_app.tmp.c:8458)
==11296==    by 0x11D339: main (test_app.tmp.c:8662)
==11296==
==11296== 1,233,408 bytes in 19,272 blocks are definitely lost in loss record 641 of 647
==11296==    at 0x4C31D2F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11296==    by 0x10AA8B: array__push (test_app.tmp.c:1042)
==11296==    by 0x11C013: vweb__run_App (test_app.tmp.c:8398)
==11296==    by 0x11D339: main (test_app.tmp.c:8662)
==11296==
==11296== 1,599,157 bytes in 19,267 blocks are definitely lost in loss record 642 of 647
==11296==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11296==    by 0x10DFEF: v_malloc (test_app.tmp.c:2924)
==11296==    by 0x10B81B: string_add (test_app.tmp.c:1514)
==11296==    by 0x112830: net__Socket_read_line (test_app.tmp.c:5764)
==11296==    by 0x11BE4E: vweb__run_App (test_app.tmp.c:8356)
==11296==    by 0x11D339: main (test_app.tmp.c:8662)
==11296==
==11296== 1,619,176 (1,233,664 direct, 385,512 indirect) bytes in 19,276 blocks are definitely lost in loss record 644 of 647
==11296==    at 0x4C31D2F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11296==    by 0x10AA8B: array__push (test_app.tmp.c:1042)
==11296==    by 0x10BCEF: string_split_single (test_app.tmp.c:1659)
==11296==    by 0x10B9B5: string_split (test_app.tmp.c:1555)
==11296==    by 0x11C09D: vweb__run_App (test_app.tmp.c:8405)
==11296==    by 0x11D339: main (test_app.tmp.c:8662)
==11296==
==11296== 4,066,216 (2,466,816 direct, 1,599,400 indirect) bytes in 19,272 blocks are definitely lost in loss record 645 of 647
==11296==    at 0x4C31D2F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11296==    by 0x10AA8B: array__push (test_app.tmp.c:1042)
==11296==    by 0x10BE69: string_split_into_lines (test_app.tmp.c:1708)
==11296==    by 0x11BEEF: vweb__run_App (test_app.tmp.c:8370)
==11296==    by 0x11D339: main (test_app.tmp.c:8662)
==11296==
==11296== 4,856,620 (3,700,352 direct, 1,156,268 indirect) bytes in 57,818 blocks are definitely lost in loss record 646 of 647
==11296==    at 0x4C31D2F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11296==    by 0x10AA8B: array__push (test_app.tmp.c:1042)
==11296==    by 0x10BCEF: string_split_single (test_app.tmp.c:1659)
==11296==    by 0x10B9B5: string_split (test_app.tmp.c:1555)
==11296==    by 0x11BFD3: vweb__run_App (test_app.tmp.c:8388)
==11296==    by 0x11D339: main (test_app.tmp.c:8662)
==11296==
==11296== 7,704,400 bytes in 19,261 blocks are definitely lost in loss record 647 of 647
==11296==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11296==    by 0x10DFEF: v_malloc (test_app.tmp.c:2924)
==11296==    by 0x1127B1: net__Socket_read_line (test_app.tmp.c:5727)
==11296==    by 0x11BE4E: vweb__run_App (test_app.tmp.c:8356)
==11296==    by 0x11D339: main (test_app.tmp.c:8662)
==11296==
==11296== LEAK SUMMARY:
==11296==    definitely lost: 21,928,272 bytes in 559,080 blocks
==11296==    indirectly lost: 3,199,314 bytes in 308,381 blocks
==11296==      possibly lost: 9,945 bytes in 119 blocks
==11296==    still reachable: 90,120 bytes in 2,925 blocks
==11296==         suppressed: 0 bytes in 0 blocks
==11296== Reachable blocks (those to which a pointer was found) are not shown.
==11296== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==11296==
==11296== For counts of detected and suppressed errors, rerun with: -v
==11296== ERROR SUMMARY: 54 errors from 54 contexts (suppressed: 0 from 0)
@jrmuizel jrmuizel added the Type: Bug label Sep 3, 2019
@medvednikov

This comment has been minimized.

Copy link
Member

@medvednikov medvednikov commented Sep 5, 2019

This will be fixed this week.

@jrmuizel

This comment has been minimized.

Copy link
Author

@jrmuizel jrmuizel commented Sep 18, 2019

Still seems to be happening:

==21577== 239,600 bytes in 599 blocks are definitely lost in loss record 1,183 of 1,183
==21577==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21577==    by 0x10E25E: v_malloc (test_app.tmp.c:2886)
==21577==    by 0x113475: net__Socket_read_line (test_app.tmp.c:5800)
==21577==    by 0x11CCAF: vweb__run_App (test_app.tmp.c:8368)
==21577==    by 0x11E0CC: main (test_app.tmp.c:8645)

Is there a place where the work to fix it is being tracked?

@jrmuizel

This comment has been minimized.

Copy link
Author

@jrmuizel jrmuizel commented Feb 5, 2020

Any update on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.