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

Hi,

2012-09-01 17:22 keltezéssel, Boszormenyi Zoltan írta:
> 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.

Attached is the mylog output for the vanilla psqlODBC 09.01.0200
which also shows the infinite loop.

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