Обсуждение: Problem with Memory Leak

Hi

I am having memory leaking problem and here is the result shown from valgrind:


==1706== 1,270 bytes in 5 blocks are still reachable in loss record 353 of 426
==1706==    at 0x4C20809: malloc (vg_replace_malloc.c:149)
==1706==    by 0x5D3F431: strdup (in /lib64/libc-2.5.so)
==1706==    by 0x109484E0: PQsendQuery (in /usr/lib64/libpq.so.5.2)


Here is my source code:

static PGresult *get_pg_result(char *sql) {


    PGresult *res=NULL;
     PGresult *final_res=NULL;
    PGconn* conn = NULL;

    int ret = 0;

    db_con_t* connection_node = get_connection();


    if (connection_node == NULL) {
        free(sql);
         return  NULL;
    }




    conn = connection_node->conn;
        if (PQstatus(conn) != CONNECTION_OK){
                PQfinish(conn);
                return NULL;
        }

            ret = PQsendQuery(conn, sql);
                if (1 != ret) {


             switch_safe_free(sql);
            release_connection(connection_node);
                       return NULL;
            }

           while ((res = PQgetResult(conn))) {


                   final_res = res;
           }







    free(sql);
    return final_res;
}

Pete Kay <petedao@gmail.com> writes:
> I am having memory leaking problem and here is the result shown from valgrind:

> ==1706== 1,270 bytes in 5 blocks are still reachable in loss record 353 of 426
> ==1706==    at 0x4C20809: malloc (vg_replace_malloc.c:149)
> ==1706==    by 0x5D3F431: strdup (in /lib64/libc-2.5.so)
> ==1706==    by 0x109484E0: PQsendQuery (in /usr/lib64/libpq.so.5.2)

Well, if that trace is to be believed, it must be talking about
conn->last_query.  Which will be freed when the connection is closed
(ie PQfinish).   It looks to me like you might need to pay more
attention to closing things when you're done with them.  The logic
you quoted seems pretty full of holes: it's freeing the argument "sql"
in only some code paths, it leaves connection_node->conn as a dangling
non-null pointer in the bad-PQstatus path, it leaks non-last PGresults;
and you haven't even shown us where the connection is supposed to get
cleaned up in non-failure cases.

            regards, tom lane

Hi,
I am setting up a connection pooling obj to pool a bunch of
PGConnection object.  That is why I am not closing the PGConn object
when the query is done.

Is that the right way to do it?

thanks,
Pete

On Fri, Mar 26, 2010 at 10:54 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Pete Kay <petedao@gmail.com> writes:
>> I am having memory leaking problem and here is the result shown from valgrind:
>
>> ==1706== 1,270 bytes in 5 blocks are still reachable in loss record 353 of 426
>> ==1706==    at 0x4C20809: malloc (vg_replace_malloc.c:149)
>> ==1706==    by 0x5D3F431: strdup (in /lib64/libc-2.5.so)
>> ==1706==    by 0x109484E0: PQsendQuery (in /usr/lib64/libpq.so.5.2)
>
> Well, if that trace is to be believed, it must be talking about
> conn->last_query.  Which will be freed when the connection is closed
> (ie PQfinish).   It looks to me like you might need to pay more
> attention to closing things when you're done with them.  The logic
> you quoted seems pretty full of holes: it's freeing the argument "sql"
> in only some code paths, it leaves connection_node->conn as a dangling
> non-null pointer in the bad-PQstatus path, it leaks non-last PGresults;
> and you haven't even shown us where the connection is supposed to get
> cleaned up in non-failure cases.
>
>                        regards, tom lane
>

Pete Kay <petedao@gmail.com> writes:
> I am setting up a connection pooling obj to pool a bunch of
> PGConnection object.  That is why I am not closing the PGConn object
> when the query is done.

> Is that the right way to do it?

Well, that's fine, but you should not be complaining about some memory
associated with the PGconn not being reclaimed yet in that state.

I guess the context we are missing is why is it you are worried about
valgrind reporting a memory leak of a kilobyte or so?

            regards, tom lane