Hi Dave,
I saw the patch just now and tested it. For me it works well and I am
getting a flat trace graph.
Regards
Anoop
-----Original Message-----
From: Dave Page [mailto:dpage@vale-housing.co.uk]
Sent: Tuesday, July 19, 2005 3:53 PM
To: Marko Ristola
Cc: Anoop Kumar; pgsql-odbc@postgresql.org
Subject: RE: [ODBC] Leak repairs
> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Dave Page
> Sent: 19 July 2005 10:50
> To: Marko Ristola
> Cc: Anoop Kumar; pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] Leak repairs
>
>
> That would appear to be the last of them (at least for my
> simple testing
> at the moment). I'll commit a patch shortly.
The patch below has been committed. Oddly though, I was demonstrating
the memory leak to someone here and removed the fix to show what
shouldn't happen - the perfmon trace remained flat! Unless my previous
testing was flawed in someway, it now appears that I cannot reproduce
the remaining leak I saw. Oh well...
> BTW, I assume you got that output from the VC++ debugger -
> care to share
> how? I spent quite some time trying to persuade it to give me that and
> didn't get anywhere :-(
I saw your other email on that - thanks for the info.
Regards, Dave.
Index: qresult.c
===================================================================
RCS file: /usr/local/cvsroot/psqlodbc/psqlodbc/qresult.c,v
retrieving revision 1.50
diff -u -r1.50 qresult.c
--- qresult.c 15 Jul 2005 09:53:34 -0000 1.50
+++ qresult.c 19 Jul 2005 10:00:22 -0000
@@ -156,13 +156,17 @@
TL_Destructor(self->manual_tuples);
self->manual_tuples = NULL;
}
-
+
/*
* If conn is defined, then we may have used "backend_tuples",
so in
* case we need to, free it up. Also, close the cursor.
*/
#ifdef USE_LIBPQ
- self->backend_tuples = NULL;
+ if (self->backend_tuples)
+ {
+ free(self->backend_tuples);
+ self->backend_tuples = NULL;
+ }
if (conn && conn->pgconn && CC_is_in_trans(conn))
#else
if (conn && conn->sock && CC_is_in_trans(conn))