Re: Snapshot 08.01.0006 available for testing

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
>
>
>