Thread: UseDeclareFetch=1, Fetch=100, UseServerSidePrepare=0 causes Windows gpf in Unicode Driver versions > 08.04.0200

I've been upgrading some Windows servers from PostgreSQL 8.3.18 to 9.2.4.
Along with that I upgraded psqlODBC for the Windows clients from 8.0x.xxxx
to 09.01.0200.

All was fine until I had a customer who could consistently get a gpf in
psqlodbc35w.dll when doing an export.

Getting a copy of their database, I could reproduce as well.

Trying different driver versions, I've found no crashes with the 8.0x
psqlODBC series, but I can reproduce the gpf starting with 09.00.xxxx
through the latest 9.01.02?? that I compiled yesterday (2013/04/20) from the
git repository.

I've used UseDeclareFetch=1 and Fetch=100 since I started with PostgreSQL
back in 2008.

Now with the 09.xx.xxxx drivers I don't get a crash if I:

1. Set UseDeclareFetch=0
or
2. Set UseServerSidePrepare=1

I've got a 31MB mylog file (zipped) of an entire client session. I can
uploaded somewhere if that would help The bulk of that could be
stripped-out; probably just the first and last 1000 lines are relevant. The
actual sql is doing an update one record at a time of a numeric(14,0) value.
It updates the first two records, executes a fetch, then crashes (when
UseDeclareFetch=1 and UseServerSidePrepare=0).

These are the last lines in mylog before the gpf occurs:

[14028-1870.117][SQLExtendedFetch][14028-1870.117]PGAPI_ExtendedFetch:
stmt=03988330 rowsetSize=20
[14028-1870.117]SQL_FETCH_NEXT: num_tuples=500, currtuple=460, rowst=460
[14028-1870.118]PGAPI_ExtendedFetch: new currTuple = 479
[14028-1870.118]fetch_cursor=1, 054FEF28->total_read=500
[14028-1870.118]**** SC_fetch: non-cursor_result
[14028-1870.118]fetch: cols=42, lf=0, opts = 039883B8, opts->bindings =
03A36758, buffer[] = 03C607C8
[14028-1870.119]type = 23, atttypmod = -1

Obviously I can start using UseServerSidePrepare=1, but I'm concerned that
would be masking a bug that should be addressed.

Thanks...jack



--
View this message in context:
http://postgresql.1045698.n5.nabble.com/UseDeclareFetch-1-Fetch-100-UseServerSidePrepare-0-causes-Windows-gpf-in-Unicode-Driver-versions-08-0-tp5752790.html
Sent from the PostgreSQL - odbc mailing list archive at Nabble.com.

On 21.04.2013 20:56, ljwilson wrote:
> I've been upgrading some Windows servers from PostgreSQL 8.3.18 to 9.2.4.
> Along with that I upgraded psqlODBC for the Windows clients from 8.0x.xxxx
> to 09.01.0200.
>
> All was fine until I had a customer who could consistently get a gpf in
> psqlodbc35w.dll when doing an export.
>
> Getting a copy of their database, I could reproduce as well.
>
> Trying different driver versions, I've found no crashes with the 8.0x
> psqlODBC series, but I can reproduce the gpf starting with 09.00.xxxx
> through the latest 9.01.02?? that I compiled yesterday (2013/04/20) from the
> git repository.
>
> I've used UseDeclareFetch=1 and Fetch=100 since I started with PostgreSQL
> back in 2008.
>
> Now with the 09.xx.xxxx drivers I don't get a crash if I:
>
> 1. Set UseDeclareFetch=0
> or
> 2. Set UseServerSidePrepare=1
>
> I've got a 31MB mylog file (zipped) of an entire client session. I can
> uploaded somewhere if that would help The bulk of that could be
> stripped-out; probably just the first and last 1000 lines are relevant. The
> actual sql is doing an update one record at a time of a numeric(14,0) value.
> It updates the first two records, executes a fetch, then crashes (when
> UseDeclareFetch=1 and UseServerSidePrepare=0).

If you could reduce it to a small self-contained test program, that
would help a lot. Or if you could narrow it down to the commit that
introduced the problem, using "git bisect".

- Heikki

Using git bisect, where "good" is defined as not crashing the PostgreSQL
server nor causing a gpf in the client program, and "bad" does one or the
other):

Last "good" commit:
http://git.postgresql.org/gitweb/?p=psqlodbc.git;a=commit;h=3cf4dedfbb435f653785a967e951956046f0a8cb
<http://git.postgresql.org/gitweb/?p=psqlodbc.git;a=commit;h=3cf4dedfbb435f653785a967e951956046f0a8cb>

The commit right after that actually crashes the PostgreSQL 9.2.4 server--I
don't get a chance to get a gpf at the client when running my test:

(this is in the server log)
2013-04-22 15:47:04 EDT    LOG    server process (PID 13732) was terminated by
exception 0xC0000005

First "bad" commit:
http://git.postgresql.org/gitweb/?p=psqlodbc.git;a=commit;h=6e45dcb08093d81f244ad6321cbd529d0a7efe61
<http://git.postgresql.org/gitweb/?p=psqlodbc.git;a=commit;h=6e45dcb08093d81f244ad6321cbd529d0a7efe61>

Note that this "bad" commit requires 09.00 headers to compile (though
version is still at 08.04), otherwise get two unresolved externals:

loadlib.obj : error LNK2019: unresolved external symbol _PQescapeLiteral
referenced in function _connect_with_param_available
loadlib.obj : error LNK2019: unresolved external symbol _PQconnectdbParams
referenced in function _CALL_PQconnectdbParams
.\Release\psqlodbc35w.dll : fatal error LNK1120: 2 unresolved externals

Apparently those two symbols were introduced in the 09.00 code stream.

Thanks...jack





--
View this message in context:
http://postgresql.1045698.n5.nabble.com/UseDeclareFetch-1-Fetch-100-UseServerSidePrepare-0-causes-Windows-gpf-in-Unicode-Driver-versions-08-0-tp5752790p5752937.html
Sent from the PostgreSQL - odbc mailing list archive at Nabble.com.

Hi Jack,

(2013/04/22 2:56), ljwilson wrote:
> I've been upgrading some Windows servers from PostgreSQL 8.3.18 to 9.2.4.
> Along with that I upgraded psqlODBC for the Windows clients from 8.0x.xxxx
> to 09.01.0200.
>
> All was fine until I had a customer who could consistently get a gpf in
> psqlodbc35w.dll when doing an export.
>
> Getting a copy of their database, I could reproduce as well.
>
> Trying different driver versions, I've found no crashes with the 8.0x
> psqlODBC series, but I can reproduce the gpf starting with 09.00.xxxx
> through the latest 9.01.02?? that I compiled yesterday (2013/04/20) from the
> git repository.
>
> I've used UseDeclareFetch=1 and Fetch=100 since I started with PostgreSQL
> back in 2008.
>
> Now with the 09.xx.xxxx drivers I don't get a crash if I:
>
> 1. Set UseDeclareFetch=0
> or
> 2. Set UseServerSidePrepare=1
>
> I've got a 31MB mylog file (zipped) of an entire client session. I can
> uploaded somewhere if that would help

Could you please upload it somewhere?

regards,
Hiroshi Inoue