Обсуждение: Dependency problems with 8.02.0100 (was Latest ODBC driver?)
Apologies for starting a new thread for this, due to the selfish reason that my ML gateway isn't very good at handling long ones :-) Dependency Walker v2.1 applied to psqlodbc*.dll drivers on NT4W SP6a machines as previously discussed. Hope I've got this right. On the machine with ODBC drivers 3.50.33.8 and psqlodbc*.dll 8.02.0100: ----------------------------------------------------------------------- psqlodbc30a.dll refers to xolehlp.dll (ordinal 5, no name) which is missing. libpq.dll refers to krb5_32.dll, which in turn refers to secur32.dll (LsaCallAuthenticationPackage, LsaConnectUntrusted, LsaLookupAuthenticationPackage, LsaFreeReturnBuffer, LsaGetLogonSessionBuffer) which is missing. psqlodbc35w.dll seems to have the same missing dependencies. On the machine with ODBC drivers 3.0.28.2 and psqlodbc*.dll 8.01.0200: ---------------------------------------------------------------------- There is no indication of a missing dependency on xolehlp.dll, despite the fact that the file does not exist on this machine. libpq.dll refers to krb5_32.dll, which in turn refers to secur32.dll with functions missing as above. However this didn't appear to lead to a fatal error so may be benign. Applying Dependency Walker to the failing app shows it to be clean. Checking psqlodbc.dll from 7.02 shows that its only direct dependencies are kernel DLLs, i.e no reference to xolehlp.dll etc. Same for psqlodbc30.dll and psqlodbc30w.dll. Hope this helps. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
On 1/9/06 17:25, "Mark Morgan Lloyd" <markMLl.pgsql-odbc@telemetry.co.uk> wrote: > Apologies for starting a new thread for this, due to the selfish reason that > my > ML gateway isn't very good at handling long ones :-) > > Dependency Walker v2.1 applied to psqlodbc*.dll drivers on NT4W SP6a machines > as > previously discussed. Hope I've got this right. > > > On the machine with ODBC drivers 3.50.33.8 and psqlodbc*.dll 8.02.0100: > ----------------------------------------------------------------------- > > psqlodbc30a.dll refers to xolehlp.dll (ordinal 5, no name) which is missing. > > libpq.dll refers to krb5_32.dll, which in turn refers to secur32.dll > (LsaCallAuthenticationPackage, LsaConnectUntrusted, > LsaLookupAuthenticationPackage, LsaFreeReturnBuffer, LsaGetLogonSessionBuffer) > which is missing. > > psqlodbc35w.dll seems to have the same missing dependencies. > secur32.dll is probably not an issue, but xolehlp.dll is part of MSDTC which is what Hiroshi suspected the problem might be. Can you try updating your 08.02.0100 release with the DLLs from his page please, per his suggestion: > I've suspected the MSDTC support. Though I'm not sure, delay loading of > OLEHLP.dll may solve the problem. > Please try the dlls at > http://www.geocities.jp/inocchichichi/psqlodbc/index.html . Thanks, Dave.
> AAAAHHHHHH I SHOULDN'T HAVE DONE THAT............... Well I think that localises the problem a bit :-) The 8.01 driver defaults to preferring SSL, while 8.02 defaults to disabling it. If 8.02 connects to the v7 or v8 servers with SSL disabled then the result is the error dialogues and logs in the last message. If 8.02 connects to the v7 server with SSL allowed it appears to progress past the authentication but then sits there without memory usage exploding. I'll grab a log in case it's significant. If 8.02 connects to the v8 server with SSL allowed then as soon as I think nothing's happening and turn away memory usage explodes. This time I caught it before the system started thrashing and terminated the process from Task Manager. Those logs are pretty big. I'll send them as email, if anybody else wants a copy please yell over the next hour. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Mark Morgan Lloyd wrote: >> AAAAHHHHHH I SHOULDN'T HAVE DONE THAT............... >> > > Well I think that localises the problem a bit :-) > > The 8.01 driver defaults to preferring SSL, while 8.02 defaults to disabling it. > > If 8.02 connects to the v7 or v8 servers with SSL disabled then the result is > the error dialogues and logs in the last message. > I've changed the code a little and uploaded the snapshot dll. Please retry the SSL disabled mode if you have time. > If 8.02 connects to the v7 server with SSL allowed it appears to progress past > the authentication but then sits there without memory usage exploding. I'll grab > a log in case it's significant. > > If 8.02 connects to the v8 server with SSL allowed then as soon as I think > nothing's happening and turn away memory usage explodes. This time I caught it > before the system started thrashing and terminated the process from Task > Manager. I have no idea why the memory usage explode occurs. Please try UseDeclarefetch mode first. regards, Hiroshi Inoue
-----Original Message----- From: Mark Morgan Lloyd [mailto:markMLl.out@telemetry.co.uk] Sent: Fri 9/1/2006 9:45 PM Cc: Dave Page; inoue@tpf.co.jp Subject: Re: [ODBC] Dependency problems with 8.02.0100 (was Latest ODBC driver?) > Done. Working on the test machine with ODBC 3.50, attempting to connect to the > v7 database gives me a dialogue "Unknown user name or password. Sending the > authentication packet failed; Could not flush the socket buffer." If I try to > connect to the v8 database I get "Unknown user name or password. Unexpected > protocol character='; Socket has been closed." Wierd. What protocol version do you have set in the driver options? Regards, Dave
Dave Page wrote: > > Done. Working on the test machine with ODBC 3.50, attempting to connect to > > the v7 database gives me a dialogue "Unknown user name or password. Sending > > the authentication packet failed; Could not flush the socket buffer." If I > > try to connect to the v8 database I get "Unknown user name or password. > > Unexpected protocol character='; Socket has been closed." > > Wierd. What protocol version do you have set in the driver options? On page 2 of the dialogue the protocol section is disabled but appears to be set to 7.4. I should of course have thought of that before testing against the old v7 server :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Hiroshi Inoue wrote: > I've changed the code a little and uploaded the snapshot dll. > Please retry the SSL disabled mode if you have time. Spending time on this is rather more palatable than any of the alternatives, most of which involve not being to upgrade the server (hence no replication) until I've reworked the clients. 446464 Sep 2 09:25 psqlodbc30a.dll 1013 Sep 2 01:35 pgxalib.exp 2290 Sep 2 01:35 pgxalib.lib Above copied to .../bin on the client. With SSL disabled to the v7 server I get the same "Unknown user name [...] Cound not flush socket buffer". Changing the protocol (which is now selectable again) to 6.4+ and after about a minute I get "Read failure. No response from the backend; No response from the backend.". Switching to protocol 7.4+ talking to the v8 server, SSL disabled, the client sits there indefinitely using 50-90% CPU but doesn't blow up. > I have no idea why the memory usage explode occurs. > Please try UseDeclarefetch mode first. Appears to have no effect, but there again the memory isn't blowing up at the moment. I'll send a log for the server v8 failed session to you and Dave. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Mark Morgan Lloyd wrote: > Changing the protocol (which is now selectable again) to 6.4+ The protocol is fixed at 7.4+ unless SSL is disabled. The latest driver plus last night's DLL set to 6.4+ against the v7 server works with one out of the three apps here, the other two time out. This is better than the case with the v8.1 driver but to look at exactly what the clients are doing I'm going to have to revert to the v7 driver. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]