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

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/