[SOLVED in FTL 2.6.2] FTL Version v2.4.1 leaking memory?

BenoitSvB · May 5, 2017, 1:32am

How do you edit to make a code block?

deHakkelaar · May 5, 2017, 2:31am

Enclose it with this charracter:
`

So like this:

`Some
code`

Will look like:

Some code

Button on top of editor that looks like this <<>/> does same.

deHakkelaar · May 5, 2017, 2:32am

Was bored waiting for apt uprade (jessie to stretch):

0,30 * * * * [[ $(echo "scale=0; $(ps u -p $(pidof pihole-FTL) | grep -v USER | awk '{print $4}')*1/1" | bc -l) -ge 50 ]] && (echo "$(date +'[%F %H:%M:%S:%3N]') Warning: Memory exceeded 50% ... RESTARTING pihole-FTL" >> /var/log/pihole-FTL.log; /usr/sbin/service pihole-FTL restart) >&2>&1

EDIT: cant test bc seems I dont have this leak.

yonesmit · May 5, 2017, 5:56am

The problem is that when I use valgrind to run pihole-FTL then then pihole web interface find pihole-FTL not running (red icon and "FTL offline" message is displayed in Pi-hole Admin Console) then the memory leak don't appear. The issue only appear when web interface is open, used logged in and is communicating with pihole-FTL.

Best Regards,

yonesmit · May 5, 2017, 6:45am

Hello,
Well, finally I got valgrind running. I created a dummy process called pihole-FTL after running valgrind to fool pihole web interface so it detect pihole-FTL running. After few minutes I see memory usage growing. The valgrind output is:


==10984== HEAP SUMMARY:
==10984==     in use at exit: 10,545,748 bytes in 226 blocks
==10984==   total heap usage: 4,127 allocs, 3,901 frees, 19,193,868 bytes allocated
==10984==
==10984== 3,400,000 bytes in 34 blocks are definitely lost in loss record 20 of 21
==10984==    at 0x482F0B8: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==10984==    by 0x11271F: read_setupVarsconf (setupVars.c:58)
==10984==    by 0x110058: getTopClients (request.c:403)
==10984==    by 0x111DC7: process_request (request.c:59)
==10984==    by 0x10EDB6: connection_handler_thread (socket.c:213)
==10984==    by 0x4847294: start_thread (pthread_create.c:333)
==10984==    by 0x4944EED: clone (clone.S:114)
==10984==
==10984== 6,700,000 bytes in 67 blocks are definitely lost in loss record 21 of 21
==10984==    at 0x482F0B8: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==10984==    by 0x11271F: read_setupVarsconf (setupVars.c:58)
==10984==    by 0x10FAC8: getTopDomains (request.c:323)
==10984==    by 0x111D81: process_request (request.c:54)
==10984==    by 0x10EDB6: connection_handler_thread (socket.c:213)
==10984==    by 0x4847294: start_thread (pthread_create.c:333)
==10984==    by 0x4944EED: clone (clone.S:114)
==10984==
==10984== LEAK SUMMARY:
==10984==    definitely lost: 10,100,000 bytes in 101 blocks
==10984==    indirectly lost: 0 bytes in 0 blocks
==10984==      possibly lost: 0 bytes in 0 blocks
==10984==    still reachable: 445,748 bytes in 125 blocks
==10984==         suppressed: 0 bytes in 0 blocks

The problem seems that is at: getTopClients and getTopDomains, there is a 100.000 byte calloc that is lost in each call.

Best Regards,

gmrza · May 5, 2017, 8:00am

I've been running into the same problem.

DL6ER · May 5, 2017, 9:17am

Thanks for identifying this! Apparently, I just missed one free() call in read_setupVarsconf().

I'm at the airport and put together a bugfix for this misbehavior:

github.com/pi-hole/FTL

Don't forget to free linebuffer also when not used

pi-hole:development ← pi-hole:fix/free_setupVars_linebuffer

opened 08:58AM - 05 May 17 UTC

DL6ER

+1 -0

**By submitting this pull request, I confirm the following (please check boxes, …eg [X]) _Failure to fill the template will close your PR_:** ***Please submit all pull requests against the `development` branch. Failure to do so will delay or deny your request*** - [X] I have read and understood the [contributors guide](https://github.com/pi-hole/pi-hole/blob/master/CONTRIBUTING.md). - [X] I have checked that [another pull request](https://github.com/pi-hole/FTL/pulls) for this purpose does not exist. - [X] I have considered, and confirmed that this submission will be valuable to others. - [X] I accept that this submission may not be used, and the pull request closed at the will of the maintainer. - [X] I give this submission freely, and claim no ownership to its content. **How familiar are you with the codebase?:** 10 --- Fixes issue discovered on [Discourse](https://discourse.pi-hole.net/t/ftl-version-v2-4-1-leaking-memory/2666/25). _This template was created based on the work of [`udemy-dl`](https://github.com/nishad/udemy-dl/blob/master/LICENSE)._

FTL v2.6.1 should then be released soon.

BenoitSvB · May 5, 2017, 11:49am

2.6.1 installed; Lost connection to API after half a minute or so. Reproducable.

DL6ER · May 5, 2017, 11:50am

We know what is going on. v2.6.2 is already in the pipeline and is currently undergoing quality tests and build integration.

DL6ER · May 5, 2017, 12:09pm

Please update to FTL v2.6.2 which fixes a double-free issue I accidentally introduced that affected users that have never set any domains and/or clients to be excluded on the Settings page.

yonesmit · May 5, 2017, 12:23pm

Updated to 2.6.2.
So far all seems ok. FTL daemon not crashing and memory usage not growing.
Good work.

Best Regards,

gmrza · May 5, 2017, 12:28pm

Updated one of my pi-holes. Will see how it does overnight and then do the main one.

BenoitSvB · May 5, 2017, 12:35pm

FTL 2.6.2 looks good now. Thnx!!

gmrza · May 5, 2017, 10:33pm

Looking much better now! Memory utilisation stayed static overnight. I've killed the cron job on the main one. Web interface is subjectively faster. (Running on original Pi model B with 256M RAM, overclocked to 1GHz.)