Memory leak ~50% increase in 18 hours about dawn

[jonozzz]

Yes, but not as bad. Maybe around 1MB per ~8 hours. You can actually see it if you install collectd and have it monitor dawn.
My mobile clients are smart enough and can roam easily between APs without dawn. So I think I'll keep it off for now.

[PolynomialDivision]

Could u please try multicast or broadcast option in network settings?
Just set here 0, or 1
https://github.com/PolynomialDivision/packages/blob/master/net/dawn/files/dawn.config#L5

Currently I'm testing patches regarding TCP socket.

Edit:
You also have to adjust this https://github.com/PolynomialDivision/packages/blob/master/net/dawn/files/dawn.config#L2 to your local broadcast address.

[jonozzz]

That did not help. I'm still seeing a steady increase:

[PolynomialDivision]

That did not help. I'm still seeing a steady increase:

Thanks for trying! Would be interesting what is the difference between those APs.

[jonozzz]

Well, now I see all other APs showing different rates of memory growth. I stopped & disabled it on all APs...as I'm hunting for another rare issue that's randomly rebooting my main AP after 7-10 days and I'm not sure what's causing it.

[PolynomialDivision]

Maybe it is wrong usage of blob buffers... :/

[Ian-Clowes]

I think I'm seeing as bit of memory leakage as well in my small network I haven't started debugging it yet though.

[babarosaM33]

to find memory leak, build with gcc -ggdb -fsanitize=address -fno-omit-frame-pointer.

[Ian-Clowes]

-fsanitize=address didn't compile for the platform of my routers (not supported on that platform by GCC if I understood the message correctly). -fsanitize=leak builds OK but I don't think it is linking in the ASAN libraries, and they aren't available if I add -lasan. I found an option in OpenWRT menuconfig that enables ASAN, so am recompiling my toolchain to see if it all comes together.

[PolynomialDivision]

There were random memory allocations by the tcpsocket. Should be fixed with latest master.

If u have x86 board you can copy the unstriped binaries from build_dir, so libc.so and dawn and place them under /tmp.
You then can use valgrind to test for memory leakage.

valgrind /tmp/libc.so /tmp/dawn

Edit:
Please compile dawn without memory auditing. You can find the define in memory_utils.h.
You can test memory leakage detection with

valgrind --leak-check=full test_storage memleak

[PolynomialDivision]

==3024== 
==3024== HEAP SUMMARY:
==3024==     in use at exit: 45,592 bytes in 106 blocks
==3024==   total heap usage: 116,586 allocs, 116,480 frees, 34,175,458 bytes allocated
==3024== 
==3024== 272 bytes in 1 blocks are possibly lost in loss record 7 of 28
==3024==    at 0x480B5FC: calloc (vg_replace_malloc.c:762)
==3024==    by 0x40B022: server_cb (in /tmp/dawn)
==3024==    by 0x4C1AFAF: uloop_run_events (uloop.c:198)
==3024==    by 0x4C1AFAF: uloop_run_timeout (uloop.c:555)
==3024==    by 0x40863C: dawn_init_ubus (in /tmp/dawn)
==3024==    by 0x40312A: main (in /tmp/dawn)
==3024== 
==3024== 4,129 bytes in 1 blocks are possibly lost in loss record 25 of 28
==3024==    at 0x480967E: malloc (vg_replace_malloc.c:309)
==3024==    by 0x4C1B9F8: ustream_alloc_default (ustream.c:67)
==3024==    by 0x4C1B94B: ustream_prepare_buf (ustream.c:279)
==3024==    by 0x4C1B94B: ustream_prepare_buf (ustream.c:250)
==3024==    by 0x4C1BC72: ustream_reserve (ustream.c:290)
==3024==    by 0x4C1C272: ustream_fd_read_pending (ustream-fd.c:56)
==3024==    by 0x4C1C272: __ustream_fd_poll (ustream-fd.c:122)
==3024==    by 0x4C1AFAF: uloop_run_events (uloop.c:198)
==3024==    by 0x4C1AFAF: uloop_run_timeout (uloop.c:555)
==3024==    by 0x40863C: dawn_init_ubus (in /tmp/dawn)
==3024==    by 0x40312A: main (in /tmp/dawn)
==3024== 
==3024== 4,401 (272 direct, 4,129 indirect) bytes in 1 blocks are definitely lost in loss record 27 of 28
==3024==    at 0x480B5FC: calloc (vg_replace_malloc.c:762)
==3024==    by 0x40B022: server_cb (in /tmp/dawn)
==3024==    by 0x4C1AFAF: uloop_run_events (uloop.c:198)
==3024==    by 0x4C1AFAF: uloop_run_timeout (uloop.c:555)
==3024==    by 0x40863C: dawn_init_ubus (in /tmp/dawn)
==3024==    by 0x40312A: main (in /tmp/dawn)
==3024== 
==3024== LEAK SUMMARY:
==3024==    definitely lost: 272 bytes in 1 blocks
==3024==    indirectly lost: 4,129 bytes in 1 blocks
==3024==      possibly lost: 4,401 bytes in 2 blocks
==3024==    still reachable: 36,790 bytes in 102 blocks
==3024==         suppressed: 0 bytes in 0 blocks
==3024== Reachable blocks (those to which a pointer was found) are not shown.
==3024== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==3024== 
==3024== Use --track-origins=yes to see where uninitialised values come from
==3024== For lists of detected and suppressed errors, rerun with: -s
==3024== ERROR SUMMARY: 2778 errors from 11 contexts (suppressed: 8755 from 10)

[PolynomialDivision]

@jonozzz Is this issue still present?

[PolynomialDivision]

Please test latest master. Feel free to reopen again.