Have you seen this one?
1121712844: 17186: not freed: '0x404ef808|s1' (800 bytes) from
'qresult.c:421'
1121712844: 17186: not freed: '0x404f0c08|s1' (800 bytes) from
'qresult.c:421'
1121712844: 17186: not freed: '0x404fd008|s1' (3200 bytes) from
'qresult.c:421'
1121712844: 17186: not freed: '0x404fe008|s1' (3200 bytes) from
'qresult.c:421'
1121712844: 17186: not freed: '0x404ff008|s1' (3200 bytes) from
'qresult.c:421'
1121712844: 17186: not freed: '0x40500008|s1' (3200 bytes) from
'qresult.c:421'
1121712844: 17186: not freed: '0x40501008|s1' (3200 bytes) from
'qresult.c:421'
Line 421 allocates a buffer into QResultClass.backend_tuples.
backend_tuples will be set into NULL in QR_Destructor() with
"self->backend_tuples = NULL". I suspect, that the memory leak.
Marko Ristola
Dave Page wrote:
>
>
>
>
>>-----Original Message-----
>>From: Anoop Kumar [mailto:anoopk@pervasive-postgres.com]
>>Sent: 19 July 2005 07:35
>>To: Dave Page
>>Cc: pgsql-odbc@postgresql.org
>>Subject: RE: [ODBC] Leak repairs
>>
>>Hi Dave,
>>
>>I have tested the patch from you, and it does make the perfmon graph
>>less steep. I am applying the patch to CVS.
>>
>>
>
>
>Great, thanks. Any joy tracking down the last little bit?
>
>
>
>>Regarding the call to PGgetisnull: My mistake! I forgot to remove it,
>>thanks for pointing it out.
>>
>>
>
>No problem.
>
>I think we should put out a second snapshot sometime, as soon as the
>rest of this memory leak is fixed, and the Excel problem is sorted. Any
>progress on that one?
>
>Also we need to expose the libpq SSL option to the user, probably on the
>main connection dialogue, and obviously as a connection string option.
>At the same time, the protocol version options can be removed. I can
>probably look at that if you are pushed for time - let me know what you
>prefer.
>
>Finally, the threading problem. After discussion with Bruce Momjian and
>Magnus Hagander, we think that the --enable-thread-safety configure
>option should be used on Windows as well as other platforms as it does
>do more than just enable critical sections around non-thread safe API
>calls. I am (as time allows!) working on fixing PostgreSQL to allow
>this.
>
>Regards, Dave
>
>---------------------------(end of broadcast)---------------------------
>TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
>
