Re: 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))