Re: Help needed for the resolution of memory leak

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Sasmit Utkarsh <utkarshsasmit(at)gmail(dot)com>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Help needed for the resolution of memory leak
Date: 2024-01-18 01:05:47
Message-ID: CAHyXU0xc=ctOrr=2Z8p7zTjxtNZmb+=O1M8D9j4W17FtNZc5eQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Jan 17, 2024 at 1:14 PM Sasmit Utkarsh <utkarshsasmit(at)gmail(dot)com>
wrote:

> Hi Merlin et al.
>
> Below are some couple of observations attached as an "overview_of_code"
> and other attachments "function_def_other_details" and leak sanitizer
> report. Please assist with some clarifications given in overview_of_code
> with (***). Let me know if you need any more information
>

***How do we handle for the case clearing when PGresult object is
assigned a pointer to the data of the specified field within the
existing PGresult object?
i.e when SQL_get_tpf_rw() actually completes in each iteration?

It is your responsibility to close PGResult and PGConn objects. Each
one created must be cleaned up. This is basic libpq usage. I suggest
studying the documentation.

Start here: https://www.postgresql.org/docs/current/libpq-exec.html

Also Study here: https://www.postgresql.org/docs/current/libpq-example.html

You should not reuse a pointer unless you have cleared the object first.

****Is the leak reported due to improper handling of the above case ?
or is it due to some other flow

Your leaks look mostly due to not cleaning PGResult. However, the
real issue here is you need to learn basic libpq usage a little
better...try writing a smaller program and see when it starts to
complain about leaks.

merlin

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Merlin Moncure 2024-01-18 02:29:29 Re: Moving to Postgresql database
Previous Message Michael Nolan 2024-01-17 23:59:29 Re: undefined symbol when installing pgcrypto on 16.1