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 1u8mAV-00BPaX-6K for pgsql-general@arkaria.postgresql.org; Sat, 26 Apr 2025 20:30:35 +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 1u8mAS-006WJo-G7 for pgsql-general@arkaria.postgresql.org; Sat, 26 Apr 2025 20:30:33 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u8mAS-006WIm-3r for pgsql-general@lists.postgresql.org; Sat, 26 Apr 2025 20:30:32 +0000 Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1u8mAQ-0026rt-1i for pgsql-general@lists.postgresql.org; Sat, 26 Apr 2025 20:30:31 +0000 Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-43cfe63c592so35056855e9.2 for ; Sat, 26 Apr 2025 13:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec.at; s=google; t=1745699429; x=1746304229; darn=lists.postgresql.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:from:to:cc:subject:date :message-id:reply-to; bh=EYBFN6XN+djd5Qz6XDlyVfzBscujiVSS4ODTbllrAr4=; b=iivaRiOrJOhvQB4oYj6JdL3y8v2gb2evs7T5UncuNiBufIq2j8jUoe32LhV+1SZvcN 1zASKYWhms/58G2H2LLIuTzUp8Fpdl7Yqf7fd6dFp7GSDKOCag1JAJmcogyoCB9lVvWe rliNzIXHgKbZAacA7s5CbUKB73H8SkywKDDvgyZ7NMCOEbzIIOfFHrFT7aLqTZoh3SfV qsRze6i9/YEw/cWy9lMH7gszuSn5K3fk5nQ7bZHMEBZIJhtog4rNMnEbkrzN7CxqG2QD 8sT/o6JvBp26tqHM5HiL/GAwNj64hdZeUuB50US3O2sf29L7W+X4QMwrjzpA60vQ+q7Z wpAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745699429; x=1746304229; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=EYBFN6XN+djd5Qz6XDlyVfzBscujiVSS4ODTbllrAr4=; b=tl31EQV0FZv6V0lvnYlduiLTJQg4KOHNncZ/J7AP83kccQUf4q9RGN2JtNVDbMsaxo IFBcCuU5LIBFbRA+bpNZ76AfXMTQDuXB12XIZtU2Bhpy8YGZN8GAu2vS3vAZaXuhCBF/ y/6jpK3+bexuK5z6qx7af8eizMlNwOzseTPryNT55k4+DF3qQWf2AlTu0yjYEMxyp5Q8 TWRKMfd28NI9yisKZHTqHArqX67SEAuTNqsrKtPg++tOufEyCo+vBHH1GoOyIyw2co6H sLi4SwsF8ya8yrllJj3QiqYL4JY67pK4LrUxfH37r7Q9an2Rt3Q3JSyi51R9KEzbjEhN 3Y/A== X-Forwarded-Encrypted: i=1; AJvYcCUdFAF9xbTxHqoFVRKh1IesMWz6j8QxMdxyKq0oJqF5Y20oJgSvw7n/oims1dUYRDIruM1lX4eC/SjBdAc1@lists.postgresql.org X-Gm-Message-State: AOJu0YyWfAOjaDFHSthvvaGnGqRbQ8G8572HKFZ9eEw8yfgRc+IL3FiZ Gafp5N89M2gcvGiqMYJAmIrDUoWIAutGucgRDodCoWjJjaf9SjNoWOJSlMMKrEo= X-Gm-Gg: ASbGncvY6ymphS4EJimi2ImHPgit/p+8HxpEbawOGk1ubetlLCnqu6G+WoME4GXpFoZ FJNsiR+tjFJg4s/AsvJMJEWWZySIKA3gkBOydcfo7HAyHsCrv7UtcHgJJhHGu2KmB5AMbqKHQJp nPqKrI1yXvTHlgWTx1g/S61sOUYQWUKKK9knpTPHOzZHVyo37i4yxjTH+mPpAP71//9bGAbp0CV 0AdChJBqHRpeszd2rQOr00rpXzZk5MejURgte8KhUqHW67QVSmxNec9eAqbfj5UUvb+9MoCZnA3 uG6x6pE2KS4kXIrmDBEFvIXJPurHMR2LiF31HS9bTkPvw6BldUzlGHN5pKXq X-Google-Smtp-Source: AGHT+IEVouUt6oytBVEUubSfpiQ8LOmKxoq7FpzkdoXhOG7ILaUZtqLcNC/1MOjOkfnDYeKcAT2FUw== X-Received: by 2002:a05:600c:1550:b0:43c:ea1a:720c with SMTP id 5b1f17b1804b1-440a6607119mr61801565e9.18.1745699429462; Sat, 26 Apr 2025 13:30:29 -0700 (PDT) Received: from localhost.localdomain ([2001:871:260:129:a3fa:8630:2f71:3226]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4409d2d8842sm103827635e9.31.2025.04.26.13.30.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 26 Apr 2025 13:30:29 -0700 (PDT) Message-ID: <0a2be546e57d6088acf734f8d6a308a984e7171b.camel@cybertec.at> Subject: Re: How to properly fix memory leak From: Laurenz Albe To: Igor Korot , "pgsql-generallists.postgresql.org" Date: Sat, 26 Apr 2025 22:30:28 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.3 (3.54.3-1.fc41) MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, 2025-04-25 at 22:24 -0500, Igor Korot wrote: > Hi, ALL, >=20 > [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] >=20 > I ran this code on MSVC 2017 with VLD and according to the VLD report I = have > a memory leak on the line indicated. >=20 > Should I call PQclear() on every iteration of the loop? >=20 > 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(). Yours, Laurenz Albe