Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u8WWQ-006H4f-Oe for pgsql-general@arkaria.postgresql.org; Sat, 26 Apr 2025 03:48:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1u8WWN-000Nk4-Du for pgsql-general@arkaria.postgresql.org; Sat, 26 Apr 2025 03:48:08 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u8WWN-000Ndy-2F for pgsql-general@lists.postgresql.org; Sat, 26 Apr 2025 03:48:07 +0000 Received: from mail-oa1-x31.google.com ([2001:4860:4864:20::31]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1u8WWI-0027Dk-0d for pgsql-general@lists.postgresql.org; Sat, 26 Apr 2025 03:48:04 +0000 Received: by mail-oa1-x31.google.com with SMTP id 586e51a60fabf-2d0e86cd5b1so1744461fac.3 for ; Fri, 25 Apr 2025 20:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745639281; x=1746244081; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=OgXszybjeg8bf5BdAm0U1knVYOq9g4kfBPlqe3r0q+U=; b=gsuEo16pYqE3R4mDKTgiyzqA3N1MhJ3hKYXgb5ytrdI3kts99Se5FQK+yX+AXGlZ9q pFJO8BYIdd5er3JlqRSPPJLDe/4r1z4J3IRNuUGtylbB/CYh66sHpLepdPMND5fNEK4s WMwsYhrwk2LR9M+i9CoogWtK8Y25hLUdNe2q57ehhKDjAmqSdkm6kWe0xWUIQGh7GGxW ZMyggPAJGlaqLfVskBGPBfO27T91qQoxHHBJTpPt5vIv+hqOfSPt8crInsVZMiZkUtUq bYT2pwbHcFWCgzlv2jNpfwBp5hOQqQ0Qu8sTW+WlCXU9AHr+5BIJzjdZAMw1cb4nTM6Q TdTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745639281; x=1746244081; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OgXszybjeg8bf5BdAm0U1knVYOq9g4kfBPlqe3r0q+U=; b=bTmGHGmt21qnKEtMSVuyuhc7X2TAVedkcVKtZzYdXHNWbDDxMx3bf/C85wXxwyyDgw TVGHVl1a06DZ5ohN0Mk81B6Q3m9qiZHMGFy/ogr1gOCkatCX0/DbE6sWBLxJMg7zTdlR FqT2YuPTj4O6jQL+PqNYhMeUNuY4ulUtoNAQhs3QM4Hxr9a0OV4VSDu8jZfef2EpDpn0 rHULFPtxD+OrQsudYsR+15Y8X7tedtXwacyuVrl4EfxlAw3Z+J8K+SvOL2W6m48vDU7V o06NtLQHuHFLTjrNgMYUPYsA7QEVrbzYILz9dKYdo6QVYQxPturbAZoi7Cr/eVvx83ar JM/A== X-Gm-Message-State: AOJu0YxUSnt8YA8I+na6s6aWhKiVc65V8Vm9Lzg1impRHh7RQmxdn2IG THa7FpF+OEGbjG0UvN+7Bn0BQuq1LI1QzPmBobE59YSYT1R52fsrrXXVFUJLK+vchnv0KkhTzMt LKJxqutNNsUmXnw8Db1rlRMQCRk1QBw== X-Gm-Gg: ASbGnctF8lCvSTHu8VhDHSXh2/vB8g4Csjb6YR0sIeUIcFzQ7vjuL78sSQOdr/gRlHp g/VCWUttDa+XO+EXwbncrCA5JtzKjAaLqlYP0zwtUtjM6+vrOxnwal6g1yuDMekJgursgMBYaIO TBmYW45TYF7EtQvnLryxc8 X-Google-Smtp-Source: AGHT+IGheKWyPcOUei4sw7MPXT1+Oz5/cAksl/csT0mtepsZDZdB+CQSDlRlgJNw8qPuR88JD74BgDS8qTKZkFJ3UVc= X-Received: by 2002:a05:6870:d686:b0:29e:69a9:8311 with SMTP id 586e51a60fabf-2d99de82ac9mr3033376fac.36.1745639281026; Fri, 25 Apr 2025 20:48:01 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a05:6802:1e0e:b0:589:13f9:e937 with HTTP; Fri, 25 Apr 2025 20:48:00 -0700 (PDT) In-Reply-To: References: From: "David G. Johnston" Date: Fri, 25 Apr 2025 20:48:00 -0700 X-Gm-Features: ATxdqUEh7jCfJBsTqZW1U3ys0BU6S6X2BDPYUkWBjkyeNtLQk2PntgJEueC8OlA Message-ID: Subject: Re: How to properly fix memory leak To: Igor Korot Cc: "pgsql-generallists.postgresql.org" Content-Type: multipart/alternative; boundary="000000000000406cb50633a651dd" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000406cb50633a651dd Content-Type: text/plain; charset="UTF-8" On Friday, April 25, 2025, Igor Korot wrote: > > for( int i = 0; i < PQntuples( res ); i++ ) > { > auto temp1 = m_pimpl->m_myconv.from_bytes( PQgetvalue( > res, i, 1 ) ); > m_tablespaces.push_back( temp1 ); > } // this line gives a leak according to VLD > } > PQclear( res ); > return result; > [/code] > > I ran this code on MSVC 2017 with VLD and according to the VLD report I > have > a memory leak on the line indicated. Seems like a false positive. > > Should I call PQclear() on every iteration of the loop? > Would make processing more than a single row impossible if you throw away the result after processing one row. David J. --000000000000406cb50633a651dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Friday, April 25, 2025, Igor Korot <ikorot01@gmail.com> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for( int i =3D 0; i < PQntuples( res ); i++ = )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auto temp1 =3D m_pimpl->m_myco= nv.from_bytes( PQgetvalue(
res, i, 1 ) );
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 m_tablespaces.push_back( temp1 );=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 } // this line gives a leak according to VLD =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 PQclear( res );
=C2=A0 =C2=A0 return result;
[/code]

I ran this code on MSVC 2017=C2=A0 with VLD and according to the VLD report= I have
a memory leak on the line indicated.

Seems = like a false positive.
=C2=A0

Should I call PQclear() on every iteration of the loop?

Would make processing more than a single r= ow impossible if you throw away the result after processing one row.
<= div>
David J.

--000000000000406cb50633a651dd--