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 1u8mXP-00BVOG-13 for pgsql-general@arkaria.postgresql.org; Sat, 26 Apr 2025 20:54:15 +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 1u8mXM-006jtj-Vn for pgsql-general@arkaria.postgresql.org; Sat, 26 Apr 2025 20:54:13 +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 1u8mXM-006jta-Ht for pgsql-general@lists.postgresql.org; Sat, 26 Apr 2025 20:54:13 +0000 Received: from mail-yw1-x1134.google.com ([2607:f8b0:4864:20::1134]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1u8mXK-002E9A-0Y for pgsql-general@lists.postgresql.org; Sat, 26 Apr 2025 20:54:13 +0000 Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-6fece18b3c8so29285307b3.3 for ; Sat, 26 Apr 2025 13:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745700849; x=1746305649; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=aNeLmgW5dTzEt4/PzfJMKNZIOfDQYoeiSDUzJ7+BP5s=; b=BGC+cY7iQMFL0rYKBa5ieeEnfUG7RNtYFieJhVcXzQtFpdeiqx7LsW8YaXAxVobOQv tE0DZZJmAX8xbyh5DMLUseo22LKb2VrtBMcGtrQi/FR6L4VFxtxFPjNYT5tXwYhu0hdE rCH5tDPcXk/98/Lop1MWqlX8BxeZrBwgKqEIDQVcfJWKKXHZuJcf5oYQLjUVzYq1SDrq AziQHsCoLF7uGQLuJrar3vnsrXTPvhovGUY4zcKWTxZmbOUmcXlPh/sZn52SqAi1JAy8 0HRERuUW5ZqnbGe7bTV6545w4vvf4wDZxufQ5QTdC+2YH5llj5ZxC8tTQRRAysZdkV1G oHsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745700849; x=1746305649; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=aNeLmgW5dTzEt4/PzfJMKNZIOfDQYoeiSDUzJ7+BP5s=; b=uZQfOuB+R8BdxwdqgTnRkOAzNttAwufXifEXi1xrRRUjCwsVLwJp/P1zLGvgcNSQQJ Jo9Oqy3HrH6DQnPRt3UXKEf86B6scvDPTSoWfwzdKCMRoDtDijfhy/pQCUtudB6s1SQF xJFp674tjr1hMTrhM3sga6sfTxUoTkygkdbGsLv6gHEEzwu/dVQcFheCJ4oQVR7WQI6Y 4t1OdVDsJ660cZzfxuAo0CSWnbY0aYehTCY1P5KJS3US6OnTYn1xyJyAIvm8MH2ZcmmR 5pf+Z3LwdAuoWUitMjhQDpWt+/hmeQ2eMx+Mguok0O0cdOtao0kaw+8A8orKrM8UfzBG bCBA== X-Gm-Message-State: AOJu0YzbPAsoYLjamQkplQLTT6KAnmiUCMckAxHiYabn3xSoKcJYOfA2 lNsSECgiaAanydfqyTccV7pt2OWIpEZCluQnvquED9O89G9aOrX6W9KhOw+PyyPLKpbt+PHHV90 gt9PZLg050Q/2V+PaKajtgcxhnnM= X-Gm-Gg: ASbGncs1Ja3Srl0FAvM47b3DoPgukfsVvIf/xO+ohNHoNJYHhfdXN8LoNYwbZV/LZKJ w3Ao6g4vyjCZkQdUbZ5dTksu5EkO0qOK2tel8RGfjW+saFmPlqBcjwIhDeDQZqiWCo6Bnd5j/ID 4dT3PoXXNAX9QfL2snenrRACot0o4KAYw3YzV/ZpohKWllg0lp+W9ZisU/ X-Google-Smtp-Source: AGHT+IFWauxhBY+b8XEEA6+AVsnpi1Ucp1eVs0zqOHGzxzTcTV4yl1NtBT2w6S5r7jJST8rQuAApCm+uKN6HhSe+pxY= X-Received: by 2002:a05:690c:ed1:b0:708:4263:4117 with SMTP id 00721157ae682-708541c1159mr96603107b3.23.1745700848674; Sat, 26 Apr 2025 13:54:08 -0700 (PDT) MIME-Version: 1.0 References: <0a2be546e57d6088acf734f8d6a308a984e7171b.camel@cybertec.at> In-Reply-To: <0a2be546e57d6088acf734f8d6a308a984e7171b.camel@cybertec.at> From: Igor Korot Date: Sat, 26 Apr 2025 15:53:58 -0500 X-Gm-Features: ATxdqUFw-S9vs27Ah0RpOP_n788I1XzawSTRNXl2u5VK_-V08zxWMEZ_3frDAK8 Message-ID: Subject: Re: How to properly fix memory leak To: Laurenz Albe Cc: "pgsql-generallists.postgresql.org" Content-Type: multipart/alternative; boundary="000000000000f82ef40633b4a6a3" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f82ef40633b4a6a3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Lauren=E2=80=99s, On Sat, Apr 26, 2025 at 3:30=E2=80=AFPM Laurenz Albe wrote: > On Fri, 2025-04-25 at 22:24 -0500, Igor Korot wrote: > > Hi, ALL, > > > > [code] > > auto res =3D PQexec( m_db, m_pimpl->m_myconv.to_bytes( query.c_str(= ) > > ).c_str() ); /* ask for binary results */ > > if( PQresultStatus( res ) !=3D PGRES_TUPLES_OK ) > > { > > auto err =3D m_pimpl->m_myconv.from_bytes( PQerrorMessage( m_db= ) > ); > > errorMsg.push_back( L"Update validation table: " + err ); > > result =3D 1; > > } > > else > > { > > for( int i =3D 0; i < PQntuples( res ); i++ ) > > { > > auto temp1 =3D 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. > > > > Should I call PQclear() on every iteration of the loop? > > > > And I hope I handle the error cae properly... > > No, PQclear() would cause an error (double free). > > If it is not a spurious complaint, the leak would have to be in > m_tablespaces.push_back(). No, it is not spurious. I=E2=80=99m getting it every time I run the program. The m_tablespaces variable is declared as =E2=80=9Cstd::vector. No pointer is involved. I don=E2=80=99t see how it can produce the leak=E2=80=A6 Thank you. > > Yours, > Laurenz Albe > --000000000000f82ef40633b4a6a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Lauren=E2=80=99s,

On Sat, A= pr 26, 2025 at 3:30=E2=80=AFPM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
On Fri, 2025-04-25 at 22:24 -0500, Igor Korot wrote:<= br> > Hi, ALL,
>
> [code]
>=C2=A0 =C2=A0 =C2=A0auto res =3D PQexec( m_db, m_pimpl->m_myconv.to_= bytes( query.c_str()
> ).c_str() );=C2=A0 =C2=A0 =C2=A0 /* ask for binary results */
>=C2=A0 =C2=A0 =C2=A0if( PQresultStatus( res ) !=3D PGRES_TUPLES_OK ) >=C2=A0 =C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0auto err =3D m_pimpl->m_myconv.fro= m_bytes( PQerrorMessage( m_db ) );
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0errorMsg.push_back( L"Update val= idation table: " + err );
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0result =3D 1;
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0else
>=C2=A0 =C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for( int i =3D 0; i < PQntuples( r= es ); i++ )
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0auto temp1 =3D m_pimpl-= >m_myconv.from_bytes( PQgetvalue(
> res, i, 1 ) );
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0m_tablespaces.push_back= ( temp1 );
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} // this line gives a leak according= to VLD
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0PQclear( res );
>=C2=A0 =C2=A0 =C2=A0return result;
> [/code]
>
> I ran this code on MSVC 2017=C2=A0 with VLD and according to the VLD r= eport I have
> a memory leak on the line indicated.
>
> Should I call PQclear() on every iteration of the loop?
>
> And I hope I handle the error cae properly...

No, PQclear() would cause an error (double free).

If it is not a spurious complaint, the leak would have to be in m_tablespac= es.push_back().

N= o, it is not spurious.
I=E2=80=99m getting it every = time I run the program.

= The m_tablespaces variable is declared as =E2=80=9Cstd::vector<std::wstr= ing>. No pointer is involved.
I don=E2=80=99t see= how it can produce the leak=E2=80=A6

Thank you.



Yours,
Laurenz Albe
--000000000000f82ef40633b4a6a3--