Re: Leak repairs

> -----Original Message-----
> From: pgsql-odbc-owner(at)postgresql(dot)org
> [mailto:pgsql-odbc-owner(at)postgresql(dot)org] On Behalf Of Dave Page
> Sent: 19 July 2005 10:50
> To: Marko Ristola
> Cc: Anoop Kumar; pgsql-odbc(at)postgresql(dot)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))