Bug 996529
| Summary: | Connections fail with provided libpq.dll. Message: "Operation would block" | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | holger.schletz |
| Component: | mingw-postgresql | Assignee: | Michael Cronenworth <mike> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 19 | CC: | holger.schletz, mike |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| 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 23:56:43 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
holger.schletz
2013-08-13 11:18:17 UTC
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. https://admin.fedoraproject.org/updates/mingw-postgresql-9.2.4-2.fc19 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 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). 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.
(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. |