[Bug 230458] net/boinc_curses: leaking memory

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230458

Alexey Dokuchaev <danfe at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |danfe at FreeBSD.org
             Status|New                         |Open

--- Comment #2 from Alexey Dokuchaev <danfe at 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' RPC
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 surprisingly
found that the leaks had stopped once I've commented out
"halfdelay(REFRESH_RATE)" calls.  After that the `boinc_curses' process worked
overnight using stable 58M of RAM.

4. I've built it with -fsanitize=address -fno-omit-frame-pointer, it found 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.