From owner-freebsd-ports-bugs@freebsd.org Fri Jul 10 06:21:14 2020 Return-Path: Delivered-To: freebsd-ports-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5829A3605A1 for ; Fri, 10 Jul 2020 06:21:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4B32x61lLZz49yJ for ; Fri, 10 Jul 2020 06:21:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 3BCF43603B0; Fri, 10 Jul 2020 06:21:14 +0000 (UTC) Delivered-To: ports-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3B9803606FD for ; Fri, 10 Jul 2020 06:21:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B32x60vtsz49fG for ; Fri, 10 Jul 2020 06:21:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 01BE41D7FB for ; Fri, 10 Jul 2020 06:21:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 06A6LDiM072177 for ; Fri, 10 Jul 2020 06:21:13 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 06A6LDE9072174 for ports-bugs@FreeBSD.org; Fri, 10 Jul 2020 06:21:13 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 230458] net/boinc_curses: leaking memory Date: Fri, 10 Jul 2020 06:21:14 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: danfe@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ports-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ports-bugs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Ports bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 06:21:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230458 Alexey Dokuchaev changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |danfe@FreeBSD.org Status|New |Open --- Comment #2 from Alexey Dokuchaev --- 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.=