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/