Re: Snapshot 08.01.0006 available for testing - Mailing list pgsql-odbc

Hi,

About one memory leak ...

(Note that if you interpret the row numbers, you must decrement
the row number by about 3, because each file has at top:
#ifdef DMALLOC
#include "dmalloc.h"
#endif

My test case was to insert 100 rows and then fetched them from the database.
I used SQLExecDirect() and SQLGetData().
No SQLBindCol and no SQLBindParameter.

Here are the results of the memory leaks:


...
1131043728: 2314: not freed: '0x40489f88|s1' (5 bytes) from
'columninfo.c:115'
1131043728: 2314: not freed: '0x40489fa8|s3' (18 bytes) from 'qresult.c:379'
1131043728: 2314: not freed: '0x40489fc8|s3' (16 bytes) from 'qresult.c:412'
1131043728: 2314: not freed: '0x40489fe8|s1' (5 bytes) from
'columninfo.c:115'
1131043728: 2314: total-size count source
1131043728: 2314: 5916 51 qresult.c:98
1131043728: 2314: 1479 51 qresult.c:241
1131043728: 2314: 1224 51 columninfo.c:30
1131043728: 2314: 918 51 qresult.c:379
1131043728: 2314: 816 51 qresult.c:412
1131043728: 2314: 254 51 columninfo.c:115
1131043728: 2314: 204 51 columninfo.c:102
1131043728: 2314: 204 51 columninfo.c:99
1131043728: 2314: 204 51 columninfo.c:97
1131043728: 2314: 102 51 columninfo.c:100
1131043728: 2314: 102 51 columninfo.c:101

1131043728: 2314: 11423 561 Total of 11

So 51 is caused from 100/2+1 fetch cursor calls.

Problem:
QR_Constructor is used for every new backend fetch.
Original qres result will be forgotten in
statement.c: 939 - 3 = 936

Unfortunately QR_Destructor would close the cursor,
which is bad for Declare/Fetch.

I tried something yesterday for that, but my trial crashed.
I don't know why.

Here is a GDB stack trace.
#3 is the important one.
There qres will be forgotten with
SC_set_Result(self,res);



(gdb) i s
#0 QR_Constructor () at qresult.c:97
#1 0x4033e1b2 in LIBPQ_execute_query (self=0x4038e008, query=0xbffff4b0
"fetch 2 in SQL_CUR0x40394808")
at connection.c:1776
#2 0x4033d623 in CC_send_query (self=0x4038e008, query=0xbffff4b0 "fetch
2 in SQL_CUR0x40394808", qi=0xbffff4a0, flag=0)
at connection.c:1479
#3 0x4036185e in SC_fetch (self=0x40394808) at statement.c:937
#4 0x4035733b in PGAPI_ExtendedFetch (hstmt=0x40394808, fFetchType=1,
irow=0, pcrow=0x0, rgfRowStatus=0x0,
bookmark_offset=0, rowsetSize=1) at results.c:1487
#5 0x403679cf in SQLFetch (StatementHandle=0x40394808) at odbcapi.c:344
#6 0x40046cb2 in SQLFetch () from /usr/lib/libodbc.so.1
#7 0x0804926f in main (argc=1, argv=0xbffff834) at TestQuery.c:207

Regards, Marko

Rainer Bauer wrote:

>"Dave Page" wrote:
>
>
>
>>>>>SQL command: "SELECT col1 FROM table WHERE col2=?"
>>>>>(Note: col1 is a SERIAL, col2 a VARCHAR).
>>>>>
>>>>>Bind the input [SQLBindParameter] and output [SQLBindCol]
>>>>>parameter before
>>>>>calling SQLPrepare().
>>>>>
>>>>>The following call to SQLExecute() returns SQL_SUCCESS. But
>>>>>the first call to
>>>>>SQLFetch() produces this error message:
>>>>><1> {HY010}(3) Null statement result in PGAPI_ExtendedFetch.
>>>>>
>>>>>
>
>(...)
>
>
>
>>Sorry - when I first read both messages I somehow managed to parse
>>ServerSidePrepare as UsedeclareFetch :-(
>>
>>Yes, it does seem to be broken - the earlier fixes were for Use
>>Declare/Fetch, so I'm not overly surprised it remains broken.
>>
>>I'll look into it, however given that it's not a widely used option (and
>>isn't documented either), I'm still inclined to release 08.01.whatever
>>even if we can't figure out the correct fix in time. It's definitely a
>>less broken driver than the current stable release.
>>
>>
>
>That's no problem. The 08.01.006 driver is working without
>"ServerSidePrepare"; it's just a performance issue.
>
>However, I just turned on "UsedeclareFetch" to see if it works. There are
>_lots_ of memory leakages (in repeating patterns) when my program exits (see
>below). They all vanish if "UsedeclareFetch" is disabled. Seems like this is
>related to memory not freed in class QResultClass.
>
>Apart from that it seems to work, although I haven't done any stress tests.
>But I might find some time tomorrow to check it more thoroughly.
>
>Rainer
>
>
> Data: <ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
> Data: <        > 00 00 00 00 00 00 00 00
> Data: <@ @   ÿ > 40 00 40 00 01 00 FF 0F
> Data: <                > 13 00 00 00 13 00 00 00 12 00 00 00 19 00 00 00
> Data: <@vC  vC ÀuC €uC > 40 76 43 01 00 76 43 01 C0 75 43 01 80 75 43 01
> Data: <  ÍÍ0xC ðwC  wC > 04 00 CD CD 30 78 43 01 F0 77 43 01 00 77 43 01
> Data: <pxC 0uC xÜ9     > 70 78 43 01 30 75 43 01 78 DC 39 01 00 00 00 00
> Data: <ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ> CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
> Data: <SQL_CUR01430070 > 53 51 4C 5F 43 55 52 30 31 34 33 30 30 37 30 00
> Data: <fetch 100 in SQL> 66 65 74 63 68 20 31 30 30 20 69 6E 20 53 51 4C
> Data: <coalesce > 63 6F 61 6C 65 73 63 65 00
> Data: <relkind > 72 65 6C 6B 69 6E 64 00
> Data: <nspname > 6E 73 70 6E 61 6D 65 00
> Data: <relname > 72 65 6C 6E 61 6D 65 00
> Data: <ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
> Data: <        > 00 00 00 00 00 00 00 00
> Data: <@ @   ÿ > 40 00 40 00 01 00 FF 0F
> Data: <                > 13 00 00 00 13 00 00 00 12 00 00 00 19 00 00 00
> Data: < zC àyC  yC `yC > 20 7A 43 01 E0 79 43 01 A0 79 43 01 60 79 43 01
> Data: <  ÍÍ€ C À{C €{C > 04 00 CD CD 80 0B 43 01 C0 7B 43 01 80 7B 43 01
> Data: <€ C  yC xÜ9     > 80 7F 43 01 10 79 43 01 78 DC 39 01 00 00 00 00
> Data: <ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ> CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
> Data: <SQL_CUR01430DC0 > 53 51 4C 5F 43 55 52 30 31 34 33 30 44 43 30 00
> Data: <fetch 100 in SQL> 66 65 74 63 68 20 31 30 30 20 69 6E 20 53 51 4C
> Data: <coalesce > 63 6F 61 6C 65 73 63 65 00
> Data: <relkind > 72 65 6C 6B 69 6E 64 00
> Data: <nspname > 6E 73 70 6E 61 6D 65 00
> Data: <relname > 72 65 6C 6E 61 6D 65 00
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 5: don't forget to increase your free space map settings
>
>
>