Re: Error reporting goes into an infinite loop when compiled --with-odbcver=0x0250

Hi,

2012-09-01 11:19 keltezéssel, Hiroshi Inoue írta:
> Hi,
>
> (2012/08/31 20:21), Boszormenyi Zoltan wrote:
>> Hi,
>>
>> we had to recently test psqlODBC with an older application
>> which doesn't expect ODBC 3.x.
>>
>> The problem is that the client locks up as soon as it encounters
>> an error of any kind, like restarting the server from under the client
>> or simply executing a bad query.
>>
>> After debugging the problem and reading the code of both
>> unixODBC 2.3.1 and psqlODBC (version 09.00.0310 and 09.01.0200),
>> I discovered that the DriverManager calls the driver's SQLError()
>> and SQLGetDiagRec() in a loop
>
> Does the DriverManager call both SQLError() and SQLGetDiagRec()?

Yes, it detects which is supported and calls that in the error handler part
of SQLExecute(). In case psqlODBC is compiled using --with-odbcver=0x0250,
SQLGetDiagRec() is naturally not supported.

> Could you send me (loop part of) the Mylog output?

I attached the unixODBC tracefile (/tmp/Trace.txt), there is no "mylog"
lines in it. I execute a single "select * from test;" and this table doesn't exist.
The trace file shows that the error code is repeated ad infinitum.

But for my debugging, I didn't use the ODBC tracing, I added my extra printf()s
so I can see on the client terminal what is going on.

I wrote:
>> The attached patch fixes this problem. Though, I am not sure about
>> whether the (stapos > msglen) and (error->errorpos >= msglen)
>> checks are redundant or not.
>

----8<--------8<--------8<--------8<--------8<----
@@ -226,7 +226,17 @@ ER_ReturnError(PG_ErrorInfo **pgerror,
}
stapos = (RecNumber - 1) * error->recsize;
if (stapos > msglen)
+ {
+ if (clear_str)
+ {
+ if (error->errorpos >= msglen)
+ {
+ ER_Destructor(error);
+ *pgerror = NULL;
+ }
+ }
return SQL_NO_DATA_FOUND;
+ }
pcblen = wrtlen = msglen - stapos;
if (pcblen > error->recsize)
pcblen = error->recsize;
----8<--------8<--------8<--------8<--------8<----

It seems the two checks are indeed redundant, valgrind shows no leaks
which means ER_Destructor() is called so the second check must be true.

Best regards,
Zoltán Böszörményi

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
http://www.postgresql.at/