Date: Fri, 10 Jul 2020 06:21:14 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 230458] net/boinc_curses: leaking memory Message-ID: <bug-230458-7788-qu0BsKBFq6@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-230458-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-230458-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230458 Alexey Dokuchaev <danfe@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |danfe@FreeBSD.org Status|New |Open --- Comment #2 from Alexey Dokuchaev <danfe@FreeBSD.org> --- I've spend two days debugging this, and here are my findings: 1. It does indeed leak memory, at various rates, but it's pretty visible in= the top(1) output. Yes, it would eventually be killed due to running out of swap space (within a day or two, depending on the activity and amount of RAM available). 2. The leak does not happen because of improper use of `net/boinc_client' R= PC C++ APIs. All of them seem to call .clear() methods and `delete' as needed. I've commented out most of the RPC calls except init+auth+get_state and it still leaks memory. However, my quick program which simply does this: > rpc.init("localhost", GUI_RPC_PORT); > rpc.authorize(passkey); > for (;;) { > CC_STATE state; > rpc.get_state(state); > sleep(1); > state.clear(); // technically not needed, get_state() does this > } does NOT leak. 3. I've started to comment out other function calls one by one and surprisi= ngly found that the leaks had stopped once I've commented out "halfdelay(REFRESH_RATE)" calls. After that the `boinc_curses' process wor= ked overnight using stable 58M of RAM. 4. I've built it with -fsanitize=3Daddress -fno-omit-frame-pointer, it foun= d two stack buffer overruns in formatter[] arrays, but no other bugs. 5. I did not try to investigate why calling halfdelay() makes it leak. That said, if you have better understanding of what's going on, please share your thoughts. If not, but you can confirm that leaks do not occur with commented out "halfdelay(REFRESH_RATE)" calls, I guess we can commit it as "good enough" fix for the time being. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-230458-7788-qu0BsKBFq6>