 | |
Re: [BUGS] BUG #1545: LIBPQ Windows Version not calling WSACleanup for
mailing.database.pgsql-bugs mailing.database.pgsql-bugs
 |
| | Thread Tools | Display Modes |
#1
 
| |||
| |||
|
Re: [BUGS] BUG #1545: LIBPQ Windows Version not calling WSACleanup for -
05-05-2005
, 10:54 AM
|
Taken from microsoft at: http://msdn.microsoft.com/library/de...us/winsock/win sock/wsastartup_2.asp ------------------------------------------------------- An application must call one WSACleanup call for every successful WSAStartup call to allow third-party DLLs to make use of a WS2_32.DLL on behalf of an application. This means, for example, that if an application calls WSAStartup three times, it must call WSACleanup three times. The first two calls to WSACleanup do nothing except decrement an internal counter; the final WSACleanup call for the task does all necessary resource deallocation for the task. ------------------------------------------------------------------ The only place WSACleanup is being called is libpqdll when the process detaches the DLL (if the libpq is not staticly linked in), which matches up with the WSAStartup when the process attaches to the DLL. The WSAStartup in the fe-connect.c->makeEmptyPGconn() does not have a matching WSACleanup. WSACleanup could possibly be placed in freePGconn(), but unsure if all possible error cases will go through this function. This problem exists in both 8.0.1 and 7.4.7 of the libpq interface for Windows. |
patch to current CVS and to 8.0.X. 8.0.3 is being packaged now so I
will wait for 8.0.4.
--
Bruce Momjian | http://candle.pha.pa.us
pgman (AT) candle (DOT) pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
--ELM1115308407-15549-0_
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
Content-Disposition: inline; filename="/pgpatches/dll"
Index: src/interfaces/libpq/fe-connect.c
================================================== =================
RCS file: /cvsroot/pgsql/src/interfaces/libpq/fe-connect.c,v
retrieving revision 1.304
diff -c -c -r1.304 fe-connect.c
*** src/interfaces/libpq/fe-connect.c 25 Mar 2005 00:34:29 -0000 1.304
--- src/interfaces/libpq/fe-connect.c 5 May 2005 15:43:06 -0000
***************
*** 2034,2039 ****
--- 2034,2043 ----
PGnotify *notify;
pgParameterStatus *pstatus;
+ #ifdef WIN32
+ WSACleanup();
+ #endif
+
if (!conn)
return;
--ELM1115308407-15549-0_
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
--ELM1115308407-15549-0_--
#2
| |||
| |||
|
|
I agree freePGconn() is the proper place. I will apply the following patch to current CVS and to 8.0.X. 8.0.3 is being packaged now so I will wait for 8.0.4. |
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
#3
| |||
| |||
|
|
Jason Erickson wrote: The only place WSACleanup is being called is libpqdll when the process detaches the DLL (if the libpq is not staticly linked in), which matches up with the WSAStartup when the process attaches to the DLL. The WSAStartup in the fe-connect.c->makeEmptyPGconn() does not have a matching WSACleanup. WSACleanup could possibly be placed in freePGconn(), but unsure if all possible error cases will go through this function. This problem exists in both 8.0.1 and 7.4.7 of the libpq interface for Windows. I agree freePGconn() is the proper place. I will apply the following patch to current CVS and to 8.0.X. 8.0.3 is being packaged now so I will wait for 8.0.4. |
one in DLL attach, isn't that sufficient?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly
#4
| |||
| |||
|
|
The only place WSACleanup is being called is libpqdll when=20 the process detaches the DLL (if the libpq is not staticly linked in),=20 which matches up with the WSAStartup when the process attaches to the DLL. =20 The WSAStartup in the fe-connect.c->makeEmptyPGconn() does=20 not have a matching WSACleanup. WSACleanup could possibly be placed=20 in freePGconn(), but unsure if all possible error cases will go through this=20 function. =20 This problem exists in both 8.0.1 and 7.4.7 of the libpq=20 interface for Windows. I agree freePGconn() is the proper place. I will apply the following patch to current CVS and to 8.0.X. 8.0.3 is being packaged now so I will wait for 8.0.4. Actually ... why do we need a WSAStartup in makeEmptyPGconn?=20=20 If we have one in DLL attach, isn't that sufficient? |
I *think* that's why it was added. In the beginning it was only in the
DLL attach code, and if you were using the library as a static lib you
had to call it yourself. Not sure when that changed, but clearly that is
when the WSACleanup() call should've gone in.
//Magnus
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
#5
| |||
| |||
|
|
Actually ... why do we need a WSAStartup in makeEmptyPGconn? If we have one in DLL attach, isn't that sufficient? Not if you link libpq as a static lib... I *think* that's why it was added. In the beginning it was only in the DLL attach code, and if you were using the library as a static lib you had to call it yourself. Not sure when that changed, but clearly that is when the WSACleanup() call should've gone in. |
Bruce, you should probably back-patch for as far as the WSAStartup call
is there, which looks to be 7.4.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
#6
| |||
| |||
|
|
Bruce Momjian <pgman (AT) candle (DOT) pha.pa.us> writes: Jason Erickson wrote: The only place WSACleanup is being called is libpqdll when the process detaches the DLL (if the libpq is not staticly linked in), which matches up with the WSAStartup when the process attaches to the DLL. The WSAStartup in the fe-connect.c->makeEmptyPGconn() does not have a matching WSACleanup. WSACleanup could possibly be placed in freePGconn(), but unsure if all possible error cases will go through this function. This problem exists in both 8.0.1 and 7.4.7 of the libpq interface for Windows. I agree freePGconn() is the proper place. I will apply the following patch to current CVS and to 8.0.X. 8.0.3 is being packaged now so I will wait for 8.0.4. Actually ... why do we need a WSAStartup in makeEmptyPGconn? If we have one in DLL attach, isn't that sufficient? |
when we are doing a WIN32_CLIENT_ONLY build from one of the *.mak files
with MSVC or BCC. It isn't linked in using the standard Makefile under
MinGW.
Seems the proper solution is to link in libpqdll.c for all Win32 builds,
and remove the WSAStartup() call from fe-connect.c, rather than call it
for every connection request. Of course that is only for CVS HEAD.
However, the addition of WSACleanup() is so minor and hard to test that
I would rather do it after 8.0.3 is packaged.
--
Bruce Momjian | http://candle.pha.pa.us
pgman (AT) candle (DOT) pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
#7
| |||
| |||
|
|
The only place WSACleanup is being called is libpqdll when the process detaches the DLL (if the libpq is not staticly linked in), which matches up with the WSAStartup when the process attaches to the DLL. The WSAStartup in the fe-connect.c->makeEmptyPGconn() does not have a matching WSACleanup. WSACleanup could possibly be placed in freePGconn(), but unsure if all possible error cases will go through this function. This problem exists in both 8.0.1 and 7.4.7 of the libpq interface for Windows. I agree freePGconn() is the proper place. I will apply the following patch to current CVS and to 8.0.X. 8.0.3 is being packaged now so I will wait for 8.0.4. Actually ... why do we need a WSAStartup in makeEmptyPGconn? If we have one in DLL attach, isn't that sufficient? Not if you link libpq as a static lib... I *think* that's why it was added. In the beginning it was only in the DLL attach code, and if you were using the library as a static lib you had to call it yourself. Not sure when that changed, but clearly that is when the WSACleanup() call should've gone in. |
--
Bruce Momjian | http://candle.pha.pa.us
pgman (AT) candle (DOT) pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
#8
| |||
| |||
|
|
"Magnus Hagander" <mha (AT) sollentuna (DOT) net> writes: Actually ... why do we need a WSAStartup in makeEmptyPGconn? If we have one in DLL attach, isn't that sufficient? Not if you link libpq as a static lib... I *think* that's why it was added. In the beginning it was only in the DLL attach code, and if you were using the library as a static lib you had to call it yourself. Not sure when that changed, but clearly that is when the WSACleanup() call should've gone in. Ah. Makes sense. So adding it to freePGconn is correct. Bruce, you should probably back-patch for as far as the WSAStartup call is there, which looks to be 7.4. |
release for untestable code.
--
Bruce Momjian | http://candle.pha.pa.us
pgman (AT) candle (DOT) pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
#9
| |||
| |||
|
|
The following bug has been logged online: Bug reference: 1545 Logged by: Jason Erickson Email address: jerickso (AT) indian (DOT) com PostgreSQL version: 8.0.1,7.4.7 Operating system: Windows Description: LIBPQ Windows Version not calling WSACleanup for every WSAStartup Details: Taken from microsoft at: http://msdn.microsoft.com/library/de...us/winsock/win sock/wsastartup_2.asp ------------------------------------------------------- An application must call one WSACleanup call for every successful WSAStartup call to allow third-party DLLs to make use of a WS2_32.DLL on behalf of an application. This means, for example, that if an application calls WSAStartup three times, it must call WSACleanup three times. The first two calls to WSACleanup do nothing except decrement an internal counter; the final WSACleanup call for the task does all necessary resource deallocation for the task. ------------------------------------------------------------------ The only place WSACleanup is being called is libpqdll when the process detaches the DLL (if the libpq is not staticly linked in), which matches up with the WSAStartup when the process attaches to the DLL. The WSAStartup in the fe-connect.c->makeEmptyPGconn() does not have a matching WSACleanup. WSACleanup could possibly be placed in freePGconn(), but unsure if all possible error cases will go through this function. This problem exists in both 8.0.1 and 7.4.7 of the libpq interface for Windows. ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster |
Bruce Momjian | http://candle.pha.pa.us
pgman (AT) candle (DOT) pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.