Re: [Python-Dev] Who understands _ssl.c on Windows?
[Tim Peters wrote] > In fact, that reminds me I added a "delete all the .pyc files" step to > the Windows buildbot clean.bat precisely so I didn't have to burn time > and space backing up 1600 stale files each day. So -0 on changing. Good enough for me. Let's not bother. Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Who understands _ssl.c on Windows?
[Neal Norwitz] > Maybe we should clean before we configure/compile? That would leave > the last build in tact until the next run. It doesn't matter much to me -- I do all changes and checkins from a non-buildbot checkout. The one thing I like about the current scheme is that when I run my daily incremental backup, I don't have to wait on backing up mounds of stale .pyc and .pyd files left from the last buildbot run. In fact, that reminds me I added a "delete all the .pyc files" step to the Windows buildbot clean.bat precisely so I didn't have to burn time and space backing up 1600 stale files each day. So -0 on changing. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Who understands _ssl.c on Windows?
[Trent]
> C:\trentm\src\python\python\PCbuild>python_d
> Python 2.5a1 (trunk, Apr 10 2006, 14:48:00) [MSC v.1310 32 bit (Intel)]
> on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import socket
> [25133 refs]
> >>> s = socket.socket()
> [25145 refs]
> >>> s.settimeout(30.0)
> [25145 refs]
> >>> s.connect(("gmail.org", 995))
> [25145 refs]
> >>>
>
> Sorry that I took so long to run this. It is a little unfortunate that
> with the last build step being "clean", I couldn't just cd into the
> build directory and try to run this.
>
> Seems like that was a good thing that I did take so long because it
> passed in the most recent build :)
>
> http://www.python.org/dev/buildbot/trunk/x86%20W2k%20trunk/builds/371/step-test/0
Excellent! Thanks to the buildbot's blamelist, we can definitely
conclude that your Win2K box's problem was cured by Andrew checking in
a change to whatsnew25.tex. Works for me :-)
> ...
> It is possible that this was due to network changes that we are doing at
> work here. We are preparing for an office move in a couple of weeks
> (http://blogs.activestate.com/activestate/2006/02/free_as_in_will.html).
> My eyes glaze over whenever the systems dudes mention VPN, SSH, DNS,
> VMWare, sub-domains and DHCP in the same breath.
Ya, life will get a lot better if you leave the sysadmins behind ;-)
Good luck with the move and the heady wine of corporate independence,
BTW -- and be sure to visit the old folks on holidays.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Who understands _ssl.c on Windows?
[Neal Norwitz wrote] > On 4/10/06, Trent Mick <[EMAIL PROTECTED]> wrote: > > > > Sorry that I took so long to run this. It is a little unfortunate that > > with the last build step being "clean", I couldn't just cd into the > > build directory and try to run this. > > Maybe we should clean before we configure/compile? That would leave > the last build in tact until the next run. Sure. Have to make sure that it doesn't choke on the bootstrapping problem: the first time there is no "Makefile" with which to call "make clean". Then again, maybe it is a good thing that one is discouraged from poking around in a buildbot build tree (potentially leaving turds that taint future builds). Thoughts? Trent -- Trent Mick [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Who understands _ssl.c on Windows?
On 4/10/06, Trent Mick <[EMAIL PROTECTED]> wrote: > > Sorry that I took so long to run this. It is a little unfortunate that > with the last build step being "clean", I couldn't just cd into the > build directory and try to run this. Maybe we should clean before we configure/compile? That would leave the last build in tact until the next run. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Who understands _ssl.c on Windows?
[Tim Peters wrote]
> Trent (and anyone else who wants to play along), what happens if you
> do this by hand in a current trunk or 2.4 build?:
>
> import socket
> s = socket.socket()
> s.settimeout(30.0)
> s.connect(("gmail.org", 995))
>
> On my box (when gmail.org:995 responds at all), the connect succeeds
> in approximately 0.03 seconds, giving 29.97 seconds to spare ;-)
C:\trentm\src\python\python\PCbuild>python_d
Python 2.5a1 (trunk, Apr 10 2006, 14:48:00) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
[25133 refs]
>>> s = socket.socket()
[25145 refs]
>>> s.settimeout(30.0)
[25145 refs]
>>> s.connect(("gmail.org", 995))
[25145 refs]
>>>
Sorry that I took so long to run this. It is a little unfortunate that
with the last build step being "clean", I couldn't just cd into the
build directory and try to run this.
Seems like that was a good thing that I did take so long because it
passed in the most recent build :)
http://www.python.org/dev/buildbot/trunk/x86%20W2k%20trunk/builds/371/step-test/0
> Can you identify a reason for why it times out on the Win2K buildbot?
> (beats me -- firewall issue, DNS sloth, ...?)
It is possible that this was due to network changes that we are doing at
work here. We are preparing for an office move in a couple of weeks
(http://blogs.activestate.com/activestate/2006/02/free_as_in_will.html).
My eyes glaze over whenever the systems dudes mention VPN, SSH, DNS,
VMWare, sub-domains and DHCP in the same breath.
Trent
--
Trent Mick
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Who understands _ssl.c on Windows?
Tim Peters wrote: > Anyone: is it "a bug" or "a feature" that a socket.connect() call > that times out may raise either socket.timeout or socket.error? > Trent's box raises socket.error. On my box, when I set a timeout > value small enough so that it _does_ time out, socket.timeout is > raised: That should give another clue as to what happened: It is *not* the select call that timed out - this would have raised a socket_timeout exception, due to internal_connect setting the timeout variable. Looking at the code, the following operations might have caused this error 10060: - getsockaddrarg - connect, returning WSAETIMEDOUT instead of WSAEWOULDBLOCK The code in getsockaddrarg is hard to follow, but I think it should only ever cause socket.gaierror. So why would connect ignore the non-blocking mode? the earlier call to ioctlsocket might have failed - unfortunately, we wouldn't know about that, because the return value of ioctlsocket (and all other system calls in internal_setblocking) is ignored. You might want to take a look at this KB article: http://support.microsoft.com/kb/179942/EN-US/ which claims that the WSA_FLAG_OVERLAPPED flag must be set on a socket on NT 4.0 for non-blocking mode to work. This shouldn't matter here, as the system is W2k, and because we used the socket API to create the socket (right?). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Who understands _ssl.c on Windows?
So Martin fixed _ssl.c on Windows (thanks! what a subtle pit that
turned out to be), and I restored the test_timeout() test in
test_socket_ssl. That test was introduced on Bug Day, but:
a) First got fiddled to exclude Windows, because the _ssl.c bug made it
impossible for the test to pass on Windows; and,
b) Then got disabled on all boxes, because the gmail.org address it tried
to connect to stopped responding to anyone, and all buildbot test runs
on all non-Windows boxes failed as a result for hours that day.
We have one oddity remaining: now that test fails on, and only on,
Trent's "x86 W2k trunk" buildbot. It always times out there, and
never times out elsewhere. It times out during a socket.connect()
call on that buildbot. The socket timeout is set to 30 seconds (seems
a very long time, right?).
Trent (and anyone else who wants to play along), what happens if you
do this by hand in a current trunk or 2.4 build?:
import socket
s = socket.socket()
s.settimeout(30.0)
s.connect(("gmail.org", 995))
On my box (when gmail.org:995 responds at all), the connect succeeds
in approximately 0.03 seconds, giving 29.97 seconds to spare ;-)
Can you identify a reason for why it times out on the Win2K buildbot?
(beats me -- firewall issue, DNS sloth, ...?)
Anyone: is it "a bug" or "a feature" that a socket.connect() call
that times out may raise either socket.timeout or socket.error?
Trent's box raises socket.error. On my box, when I set a timeout
value small enough so that it _does_ time out, socket.timeout is
raised:
>>> import socket
>>> s = socket.socket()
>>> s.settimeout(0.01)
>>> s.connect(("gmail.org", 995))
Traceback (most recent call last):
File "", line 1, in
File "", line 1, in connect
socket.timeout: timed out
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Who understands _ssl.c on Windows?
Georg Brandl wrote: > A mailing list post found via Google suggests that Visual Studio automatically > sets the struct member alignment to 4 bytes when building via old .mak files, > for compatibility with older VC++. Most likely, the poster didn't understand what's going on. I very much doubt nmake does such a thing. More likely, their makefile had the same bug as ours (i.e. lacking a WIN32 define). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Who understands _ssl.c on Windows?
Tim Peters wrote: > _Perhaps_ it's the case that doubles are aligned to an 8-byte boundary > when socketmodule.c is compiled, but (for some unknown reason) only to > a 4-byte boundary when _ssl.c is compiled. This is indeed what happens, because of what I consider three bugs: one in Python, and two in the Platform SDK: - _ssl.mak fails to define WIN32; this is bug 1 - because of that, WinSock2.h includes pshpack4.h at the beginning (please take a look at the comment above that include) - WinSock2.h includes windows.h (and some other stuff). This ultimately *defines* WIN32. I haven't traced where exactly it gets defined, but verified that it does before the end of WinSock2.h. Most likely, it comes from Ole2.h. This is bug 2: if WIN32 is a flag to the SDK headers, they shouldn't set it themselves. If they want to assume it is always defined, they should just make the things that it currently affects unconditional. - WinSock2 then includes poppack.h, under the same condition (WIN32 not defined) as pshpack4.h. This is bug 3: the code assumes that the condition doesn't change, but it might. They should instead set a macro (say, WINSOCK2_PSHPACK4) at push time, and then check for it to determine if they need to pop. Anyway, the fix is then straight-forward: just add /DWIN32 to _ssl.mak. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Who understands _ssl.c on Windows?
Michael Hudson wrote: > "Tim Peters" <[EMAIL PROTECTED]> writes: > >> _Perhaps_ it's the case that doubles are aligned to an 8-byte boundary >> when socketmodule.c is compiled, but (for some unknown reason) only to >> a 4-byte boundary when _ssl.c is compiled. Although that seems to >> match the details in the bug report, I have no theory for how that >> could happen (I don't see any MS packing pragmas anywhere). > > Well, poking a bit reveals that _ssl and _socket are built by quite > different mechanisms: _socket by a .vcproj but _ssl by "_ssl.mak". I > don't see anything overly suspicious in _ssl.mak, but I don't really > know much about Windows compiler options... A mailing list post found via Google suggests that Visual Studio automatically sets the struct member alignment to 4 bytes when building via old .mak files, for compatibility with older VC++. Anyway, a /Zp8 flag should correct this. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Who understands _ssl.c on Windows?
"Tim Peters" <[EMAIL PROTECTED]> writes: > _Perhaps_ it's the case that doubles are aligned to an 8-byte boundary > when socketmodule.c is compiled, but (for some unknown reason) only to > a 4-byte boundary when _ssl.c is compiled. Although that seems to > match the details in the bug report, I have no theory for how that > could happen (I don't see any MS packing pragmas anywhere). Well, poking a bit reveals that _ssl and _socket are built by quite different mechanisms: _socket by a .vcproj but _ssl by "_ssl.mak". I don't see anything overly suspicious in _ssl.mak, but I don't really know much about Windows compiler options... Cheers, mwh -- > so python will fork if activestate starts polluting it? I find it more relevant to speculate on whether Python would fork if the merpeople start invading our cities riding on the backs of giant king crabs. -- Brian Quinlan, comp.lang.python ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Who understands _ssl.c on Windows?
An "impossible problem" showed up on Bug Day, which got more impossible the more I looked at it: http://www.python.org/sf/1462352 See that for details. The short course is that socketmodule.c and _ssl.c disagree about the offset at which the sock_timeout member of a PySocketSockObject struct lives. As a result, timeouts set on a socket "change by magic" when _ssl.c looks at them. This is certainly the case on the trunk under Windows on my box. No idea about other platforms or Python versions. When someone figures out the cause, those should be obvious ;-) _Perhaps_ it's the case that doubles are aligned to an 8-byte boundary when socketmodule.c is compiled, but (for some unknown reason) only to a 4-byte boundary when _ssl.c is compiled. Although that seems to match the details in the bug report, I have no theory for how that could happen (I don't see any MS packing pragmas anywhere). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
