Red Hat Bugzilla – Bug 996529
Connections fail with provided libpq.dll. Message: "Operation would block"
Last modified: 2013-08-31 20:01:01 EDT
Description of problem:
Applications using the libpq.dll provided by the package fail to connect to the database with the following message:
Connection to database failed: could not connect to server: Operation would bloc
Is the server running on host "myserver" (22.214.171.124) and accepting TCP/IP connections on port 5432?
(Hostname and IP adress are placeholders here, the actual message contains the real values.)
That's not a problem with the database setup. If I replace libpq.dll with the version from the binary package from the PostgreSQL website, the connection succeeds.
Version-Release number of selected component (if applicable):
Always, with any application. Tested on Windows XP and Windows 7. The following example uses one of the example applications from the PostgreSQL source distribution for simplicity.
Steps to Reproduce:
1. cd <PostgreSQL source dir>/src/test/examples
2. i686-w64-mingw32-gcc testlibpq.c -lpq -o testlibpq.exe
3. Copy testlibpq.exe, /usr/i686-w64-mingw32/sys-root/mingw/bin/libpq.dll and its dependencies (see below) to a Windows machine (all in the same directory).
4. On the target machine run "testlibpq.exe [connection string]".
5. Replace libpq.dll with the version from the binary distribution and its dependencies (see below)
6. Repeat step 4, without recompiling.
Step 4 fails with the error message above. Step 6 should list all databases on the server, provided that the connection string is valid.
Both tests should succeed.
I had the same problem a couple of weeks ago when I cross-compiled libpq manually (before the Fedora package was available). The only hint I found is this discussion: http://postgresql.1045698.n5.nabble.com/Strange-Windows-problem-lock-timeout-test-request-td5741098.html
They say that cross-compiling is not officially supported and they don't show much interest in fixing the problem. The proposed alternatives do not really fit the purpose of the Fedora package.
One difference between both DLL versions, other than different build environments being used (AFAIK PostgreSQL binary is compiled natively via MSVC) is the dependencies. The Fedora version depends on libcrypto-10.dll and libssl-10.dll, while the PostgreSQL binary depends on libeay32.dll, libintl.dll and ssleay32.dll (all shipped in the binary distribution). However, I did not use SSL connections in my tests.
I can still compile my projects against the library from the Fedora package, but I have to use different DLLs on the target systems.
I had never tested the DLL as I had another problem that prevented me from testing. I do see the same behavior as do many other people (Google search). Unfortunately upstream is not responding to the bug reports for this nor my e-mail to their mailing list.
mingw-postgresql-9.2.4-2.fc19 has been submitted as an update for Fedora 19.
mingw-postgresql-9.2.4-2.fc18 has been submitted as an update for Fedora 18.
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing mingw-postgresql-9.2.4-2.fc19'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
I tested the new version with limited success. The message is gone, and the test application actually runs, but I have a new problem:
The DLL fails to load from my Qt4 application. A minimalistic example would attempt to load the library via:
qDebug() << lib.load();
That should output "true", but instead outputs "false".
Again, simply replacing libpq.dll with the "official" version, without recompiling the application, fixes the problem, so there is still something wrong with the DLL itself.
I had a look at your patch, and I found that the affected constants are already redefined somewhere else:
It appears like these headers (which do much more than that) are not included, or some externally defined constant is not set correctly. I did not test that.
I suspect a misdetection of environment by the configure script. That would explain why there are no problems when the code is built via MinGW/MSYS on a Windows system.
(In reply to holger.schletz from comment #5)
> I suspect a misdetection of environment by the configure script. That would
> explain why there are no problems when the code is built via MinGW/MSYS on a
> Windows system.
Not the case.
I would suggest you report the other issues upstream.
OK, that was just a blind guess.
After further testing, I found out that the problem occurs only with Qt4. When compiling the same application with Qt5, everything runs fine.
I don't think Qt4 is to blame alone because it works with the other DLL. There seems to be a specific incompatibility that occurs only with that particular combination of Qt4 and the package-provided DLL.
Is there any additional debug message that could be retrieved from lib.load()?
Have you attempted to use the native LoadLibrary() call?
QLibrary::load() returns just a boolean indicating success or failure. QLibrary::errorString() gives me the not-so-helpful "unknown error".
I haven't tested LoadLibrary() directly as I'm not familiar with the Win32 API. I had a look at the source code of both Qt versions and the LoadLibrary() calls look identical. I could test that next week.
Calling LoadLibrary directly within my application gave the same results: works with Qt5, fails with Qt4. Unfortunately, I could not reproduce the problem with a minimal test application.
Profiling with Dependency Walker (http://www.dependencywalker.com/) gave the following lines on startup of the failing application:
Loaded "LIBPQ.DLL" at address 0x003B0000 by thread 1. Successfully hooked module.
First chance exception 0xC0000005 (Access Violation) occurred in "NTDLL.DLL" at address 0x776F4D15 by thread 1.
Unloaded "LIBPQ.DLL" at address 0x003B0000 by thread 1
The manual LoadLibrary() call yielded:
LoadLibraryW("libpq.dll") returned NULL by thread 1. Error: Unzulässiger Zugriff auf einen Speicherbereich (998).
(The last message roughly translates to "Illegal memory access").
That's the best information I could get. Since this problem also seems to be specific to my application, I'd be OK with this bug closed. I'll just switch to Qt5 instead.
mingw-postgresql-9.2.4-3.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
mingw-postgresql-9.2.4-3.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.