Bug 996529 - Connections fail with provided libpq.dll. Message: "Operation would block"
Connections fail with provided libpq.dll. Message: "Operation would block"
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: mingw-postgresql (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Michael Cronenworth
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-13 07:18 EDT by holger.schletz
Modified: 2013-08-31 20:01 EDT (History)
2 users (show)

See Also:
Fixed In Version: mingw-postgresql-9.2.4-3.fc18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-31 19:56:43 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description holger.schletz 2013-08-13 07:18:17 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
k (0x00002733/10035)
Is the server running on host "myserver" (1.2.3.4) 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):

9.2.4-1.fc19

How reproducible:

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.


Actual results:

Step 4 fails with the error message above. Step 6 should list all databases on the server, provided that the connection string is valid.


Expected results:

Both tests should succeed.


Additional info:

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.
Comment 1 Michael Cronenworth 2013-08-14 20:20:31 EDT
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.
Comment 2 Fedora Update System 2013-08-15 23:21:34 EDT
mingw-postgresql-9.2.4-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/mingw-postgresql-9.2.4-2.fc19
Comment 3 Fedora Update System 2013-08-15 23:32:40 EDT
mingw-postgresql-9.2.4-2.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/mingw-postgresql-9.2.4-2.fc18
Comment 4 Fedora Update System 2013-08-16 18:58:27 EDT
Package mingw-postgresql-9.2.4-2.fc19:
* 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:
https://admin.fedoraproject.org/updates/FEDORA-2013-14871/mingw-postgresql-9.2.4-2.fc19
then log in and leave karma (feedback).
Comment 5 holger.schletz 2013-08-20 06:57:43 EDT
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:

    QLibrary lib("libpq");
    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:

include/server/pg_config_os.h
include/server/port/win32.h
include/pg_config_os.h

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.
Comment 6 Michael Cronenworth 2013-08-20 09:10:50 EDT
(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.
Comment 7 holger.schletz 2013-08-22 05:12:41 EDT
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.
Comment 8 Michael Cronenworth 2013-08-22 10:21:50 EDT
Is there any additional debug message that could be retrieved from lib.load()?

Have you attempted to use the native LoadLibrary() call?
Comment 9 holger.schletz 2013-08-22 13:35:04 EDT
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.
Comment 10 holger.schletz 2013-08-29 07:44:53 EDT
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.
Comment 11 Fedora Update System 2013-08-31 19:56:43 EDT
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.
Comment 12 Fedora Update System 2013-08-31 20:01:01 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.