Skip site navigation (1) Skip section navigation (2)

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

From: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
To: Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp>
Cc: Hiroshi Saito <hiroshi(at)winpg(dot)jp>, pgsql-odbc(at)postgresql(dot)org, Hans-Jürgen Schönig <hs(at)cybertec(dot)at>
Subject: Re: Error reporting goes into an infinite loop when compiled --with-odbcver=0x0250
Date: 2012-09-01 17:13:52
Message-ID: 50424250.602@cybertec.at (view raw or flat)
Thread:
Lists: pgsql-odbc
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/


Attachment: 10581.log.gz
Description: application/x-tar (18.8 KB)

In response to

Responses

pgsql-odbc by date

Next:From: Ross ReedstromDate: 2012-09-06 18:59:49
Subject: Re: MS Office - OS X Lion (10.7)
Previous:From: Boszormenyi ZoltanDate: 2012-09-01 15:22:52
Subject: Re: Error reporting goes into an infinite loop when compiled --with-odbcver=0x0250

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group