Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n3Z0p-00070o-4G for pgsql-hackers@arkaria.postgresql.org; Sat, 01 Jan 2022 07:41:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n3Z0m-0000Xk-AQ for pgsql-hackers@arkaria.postgresql.org; Sat, 01 Jan 2022 07:41:08 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n3Z0l-0000Xa-PO for pgsql-hackers@lists.postgresql.org; Sat, 01 Jan 2022 07:41:08 +0000 Received: from mail-oi1-x22c.google.com ([2607:f8b0:4864:20::22c]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1n3Z0e-0003A9-TW for pgsql-hackers@postgresql.org; Sat, 01 Jan 2022 07:41:07 +0000 Received: by mail-oi1-x22c.google.com with SMTP id v6so47347286oib.13 for ; Fri, 31 Dec 2021 23:41:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=LQXm+T86MMEMHiB+7E/+CDXxv0FUuGwn9dDq84tEP6s=; b=Z1fRHnSDJlEXDM/2DdICPGVqER2ef3B6vu6Ki8KQN3ml3Bzk/BxBN4YPUtPLYfvb/d hbtHdzBrFoikccGI1QHPe2oyyEntxzuya8Kgt8pnmWijLUPmbzSURsp482eHKVjWGnZ0 yaE+l9V2BSrq9YpkmwEvOubzC/UnGiMB7omcU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=LQXm+T86MMEMHiB+7E/+CDXxv0FUuGwn9dDq84tEP6s=; b=7+GZucQfBfs/i6fVdqrpGgb9z7gGthIhOV9Sz+TOwOPJ4AXoL3w8iKEB/xxIta5qLC n6B8X2N72K1agAGvWIjS+uB0WuzHlyDg6gDnVHRdTXCbrovvdOidk/BnneSG6qO4/X8J JTqD3m0/9fL7P+23C7fWxGQMGRZ5M2pcUNUIwtPE2Fw5WiAFprITi/9H1jBq1XsLveJ3 TiZObGPUmK0oJtOxu0ck4qEkkx5kVOMoGWdYjkunRAvN2PI6eLsM1dy67le520RyMQAu gF6KX7UWTOiLNdWGTFiwrnJT8cc+iupA5Xo4at8uIEkzzc+uqKPQSChN3G2wY8YZGQuR KIxg== X-Gm-Message-State: AOAM532/jeTz2INazJ46lQCPUXpcMj8cQCnc7rnT/YvljgFk7GquV1J5 ghgUrICCf2wZjYMSFzrqM8oJAJs9WxjiNUqq X-Google-Smtp-Source: ABdhPJzHm4sludtdb1SCPZuB9l8q7WAk+58ybc3AyFSLASogwAgwKT5XbM+StMtJelnQXAN2gn9oyg== X-Received: by 2002:aca:6105:: with SMTP id v5mr30240471oib.20.1641022858785; Fri, 31 Dec 2021 23:40:58 -0800 (PST) Received: from rfd.leadboat.com ([2600:1702:a20:5750::2e]) by smtp.gmail.com with ESMTPSA id e69sm5531583ote.23.2021.12.31.23.40.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Dec 2021 23:40:58 -0800 (PST) Date: Fri, 31 Dec 2021 23:40:55 -0800 From: Noah Misch To: Benoit =?iso-8859-1?Q?Lobr=E9au?= Cc: Guillaume Lelarge , PostgreSQL Developers , "Dr. Michael Meskes" Subject: Re: Probable memory leak with ECPG and AIX Message-ID: <20220101074055.GA54621@rfd.leadboat.com> References: <20211212073411.GA2218865@rfd.leadboat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Dec 15, 2021 at 04:20:42PM +0100, Benoit Lobréau wrote: > * with LDR_CNTRL=MAXDATA=0x10000000, we reach 256Mo but there is no > segfault, the program just continues running ; > * with LDR_CNTRL=MAXDATA=0x80000000, we reach 2Go and there is no segfault > either, the program just continues running. I get the same results. The leak arises because AIX freelocale() doesn't free all memory allocated in newlocale(). The following program uses trivial memory on GNU/Linux, but it leaks like you're seeing on AIX: #include int main(int argc, char **argv) { while (1) freelocale(newlocale(LC_NUMERIC_MASK, "C", (locale_t) 0)); return 0; } If you have access to file an AIX bug, I recommend doing so. If we want PostgreSQL to work around this, one idea is to have ECPG do this newlocale() less often. For example, do it once per process or once per connection instead of once per ecpg_do_prologue().