Bleadperl breaks MLEHMANN/AnyEvent-7.07.tar.gz on Windows #13764
Comments
From @chornyCreated by @chornyTests of AnyEvent fail on Strawberry Perl 5.19.11. This error did not t/handle/01_readline.t: Perl Info |
From @iabynOn Thu, Apr 24, 2014 at 11:15:49AM -0700, Alexandr Ciornii wrote:
Works for me on Linux. I guess this is a Windows-specific issue? -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From @steve-m-hayOn Fri Apr 25 04:21:47 2014, davem wrote:
Works for me too on Windows, using today's blead, compiled with VC10 and with MinGW-w64-4.8.0 (both default configuration builds, except in debug mode). The gcc build test results are attached. Loads of tests shout that my perl is BROKEN (?!), but the test in question passes. |
From @steve-m-hayC:\perl\bin\perl.exe "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib\lib', 'blib\arch')" t/*.t t/handle/*.t |
From @Corion... I just tested this against the current bleadperl on Windows 7 with This is with an uninstalled AnyEvent and without (say) EV or any other -max gcc (gcc-4.6.3 release with patches [build 20121012 by C:\Users\Corion\.cpan\build\AnyEvent-7.07-9P6WmP>perl -V Characteristics of this binary (from libperl): C:\Users\Corion\.cpan\build\AnyEvent-7.07-9P6WmP> C:\Users\Corion\.cpan\build\AnyEvent-7.07-9P6WmP>perl Makefile.PL *** ... Detected uninstalled Perl. Trying to continue. C:\Users\Corion\.cpan\build\AnyEvent-7.07-9P6WmP>perl -v This is perl 5, version 19, subversion 12 (v5.19.12 Copyright 1987-2014, Larry Wall Perl may be copied only under the terms of either the Artistic License Complete documentation for Perl, including FAQ lists, should be found on C:\Users\Corion\.cpan\build\AnyEvent-7.07-9P6WmP>dmake test C:\Users\Corion\.cpan\build\AnyEvent-7.07-9P6WmP>perl -Ilib -w |
From @bulk88no reproduce Fetching with LWP: Configuring M/ML/MLEHMANN/AnyEvent-7.07.tar.gz with Makefile.PL *** Checking if your kit is complete... Microsoft (R) Program Maintenance Utility Version 7.10.3077 cp lib/AnyEvent/Impl/Event.pm blib\lib/AnyEvent/Impl/Event.pm Microsoft (R) Program Maintenance Utility Version 7.10.3077 Skip blib\lib/AnyEvent/IO/Perl.pm (unchanged) cpan[2]> q C:\>perl -v This is perl 5, version 19, subversion 12 (v5.19.12 (v5.19.11-19-g6057286*)) bui Copyright 1987-2014, Larry Wall Perl may be copied only under the terms of either the Artistic License or the Complete documentation for Perl, including FAQ lists, should be found on C:\> self compiled VC 2003 perl on WinXP 32 bits -- |
From @rjbsClosed as this is likely the issue in https://rt-archive.perl.org/perl5/Ticket/Display.html?id=119433#txn-1291542 -- |
|
@rjbs - Status changed from 'open' to 'resolved' |
From @rjbs(Please, by all means, if you can provide steps to reproduce this which can demonstrate that it is a distinct bug, let us know. I am not trying to dismiss an unknown problem, but to suggest that the transaction linked-to above would explain a strange failure that can't be reproduced by other testers immediately.) -- |
From m.nooning@comcast.netPlease reopen this ticket. |
From m.nooning@comcast.netHmmm. I see this is judged to be the same bug as 1291542, so I will report this in that ticket instead. |
From @ikegamiOn Tue, Apr 29, 2014 at 10:13 AM, Steve Hay via RT <
Looks like the test are being run in cygwin, not Windows? |
From m.nooning@comcast.netThe tests are in a Windows command prompt. I will show the first two "not okay" lines. After this there are many such lines. I will then paste the short test summary. Test Summary Report t/handle/01_readline.t (Wstat: 35840 Tests: 3 Failed: 0) C:\Documents and Settings\Malcolm\My Documents\Downloads>perl -v This is perl 5, version 20, subversion 1 (v5.20.1) built for MSWin32-x86-multi-thread-64int Just for the exercise, I tried it on my cygwin, same machine. Cygwin has Perl v5.14.2. The cygwin attempt at "cpan install AnyEvent" looks stuck in an endless loop printing out lines like that below (slightly edited by me): Thanks |
From m.nooning@comcast.netBy the way, my Windows prompt perl says 64 bit, even though I installed it from the supposed 32 bit msi: strawberry-perl-5.20.1.1-32bit.msi Could there be a mixup on the creation of perl-5.20.1.1-32bit.msi? |
From @ikegamiOn Thu, Sep 25, 2014 at 2:29 PM, Malcolm Nooning via RT <
"MSWin32-x86-multi-thread-64int" means it's a 32-bit program (x86 instead |
From laurent.aml@gmail.comI got this issue with Strawberry Perl 5.20.2.1 (32bits, int64), on Windows 7 64bits. C:\0\strawberry-perl-5.20.2.1-32bit\cpan\build\AnyEvent-7.08-zCulrH>..\..\..\perl\bin\perl.exe -Ilib t\handle\01_readline.t AnyEvent::Handle expects syswrite to return EAGAIN(11), EINTR(4) or AnyEvent::Util::WSAEWOULDBLOCK(10035) errors when buffers are full, but syswrite returns POSIX::EWOULDBLOCK(140) instead in this case. Catching POSIX::EWOULDBLOCK in AnyEvent::Handle fixes the issue. |
From [Unknown Contact. See original ticket]I got this issue with Strawberry Perl 5.20.2.1 (32bits, int64), on Windows 7 64bits. C:\0\strawberry-perl-5.20.2.1-32bit\cpan\build\AnyEvent-7.08-zCulrH>..\..\..\perl\bin\perl.exe -Ilib t\handle\01_readline.t AnyEvent::Handle expects syswrite to return EAGAIN(11), EINTR(4) or AnyEvent::Util::WSAEWOULDBLOCK(10035) errors when buffers are full, but syswrite returns POSIX::EWOULDBLOCK(140) instead in this case. Catching POSIX::EWOULDBLOCK in AnyEvent::Handle fixes the issue. |
From @steve-m-hayOn 11 March 2015 at 19:46, Laurent Aml via RT <perlbug-comment@perl.org> wrote:
Yes, EWOULDBLOCK should be used instead of The change in EWOULDBLOCK value was caused by a series of commits http://perl5.git.perl.org/perl.git/commit/c9beaf974d The effect of that commit is that (with VC++ 2010+ and recent gcc C:\Dev\Temp\perl-5.19.3>.\perl -le "$! = 10035; print 0+$!" C:\Dev\Temp\perl-5.20.2>.\perl -le "$! = 10035; print 0+$!" As the commits noted, this level of breakage in modules testing |
From laurent.aml@gmail.comThis ticket should be reopened; current Perl is broken regarding the handling of WSA* winsock errors. Secondly, the change of the EWOULBLOCK value to 140 is a Perl decision, not dictated by VC 2010. Windows still uses 10035 for WSAEWOULDBLOCK (and returns that from winsock). VC 2010 certainly defines EWOULDBLOCK as 140, but I don't see how this particular EWOULDBLOCK is of any use in Perl? Though, doing this has intentionally introduced backward compatibility issues, to prevent some hypothetical future breakage. It is also worth noting that AnyEvent has been subtly broken for years on non-cygwin Windows Perl because EINPROGRESS has been mapped to WSAEINPROGRESS. Finally, Marc Lehmann is much more knowledgeable than me on the subject. The above technical findings are his. Please refer to the perl5-porters or AnyEvent mailing lists for more details. |
From [Unknown Contact. See original ticket]This ticket should be reopened; current Perl is broken regarding the handling of WSA* winsock errors. Secondly, the change of the EWOULBLOCK value to 140 is a Perl decision, not dictated by VC 2010. Windows still uses 10035 for WSAEWOULDBLOCK (and returns that from winsock). VC 2010 certainly defines EWOULDBLOCK as 140, but I don't see how this particular EWOULDBLOCK is of any use in Perl? Though, doing this has intentionally introduced backward compatibility issues, to prevent some hypothetical future breakage. It is also worth noting that AnyEvent has been subtly broken for years on non-cygwin Windows Perl because EINPROGRESS has been mapped to WSAEINPROGRESS. Finally, Marc Lehmann is much more knowledgeable than me on the subject. The above technical findings are his. Please refer to the perl5-porters or AnyEvent mailing lists for more details. |
From @steve-m-hayOn 18 March 2015 at 23:44, Laurent Aml via RT <perlbug-comment@perl.org> wrote:
The non-equivalence of like-named Winsock/POSIX error codes appears It was on this basis that it was assumed that anyone wishing to test The reason that EWOULDBLOCK's value has changed from 10035 to 140 is, It is true that we could always set EWOULDBLOCK to the WSAEWOULDBLOCK My worry about the latter approach (which is what you've suggested as That is why I took the former approach instead, which is a safe change Finally, on the subject of EINPROGRES vs WSAEINPROGRESS I would also The only really robust solution that I have in mind right now for how We have somebody looking into all of this right now, and hope to come I am reopening this ticket in the meantime until these issues are resolved. |
|
@steve-m-hay - Status changed from 'resolved' to 'open' |
From laurent.aml@gmail.comMorning, On Thu, Mar 19, 2015 at 5:47 AM, Steve Hay <steve.m.hay@googlemail.com>
Now that we know that the basis is false, what has been deducted from it is [...]
This sounds like a lemming argument to me: MS decides to do something, Perl
And this is what Perl had been doing happily for years. value, even when errno.h gives us a value already, but this raises the
The real issue is somewhere else actually. It does not really matter what Now, you don't mind breaking the backward compatibility for
This is what I call breaking things now in an attempt to prevent Also, converting CRT error codes to any Perl's code (such as WSA* ones) But worse, the Perl Posix error codes currently have the winsock semantics
Arguments have been given why using the Exxx constants to test winsock
have opposite meaning (success vs failure), they are also used in
Neither do I have deep knowledge on this.
Using WSA* code as in previous Perl versions is not as robust, but at least
That part is easy and does not break anything, but the constants would be
That's the tricky part. Regards, -- Laurent |
From @ap* Steve Hay <steve.m.hay@googlemail.com> [2015-03-19 10:50]:
Even if it helps, consider how you would have to write code that makes
From the outside, this seems the only real answer. Consider in particular what this means for feature detect switches in Regards, |
From @steve-m-hayOn 19 March 2015 at 18:11, Laurent <laurent.aml@gmail.com> wrote:
Evening ;-)
But it is relevant for explaining the decisions taken: If you look at
You've cut off the second half of my sentence there. Perl has not
I take exception with the first part of that paragraph. As I wrote Indeed, we seem to have further encouraged people to check for Winsock
If I understand you correctly, you are suggesting that we should do this: #ifdef EWOULDBLOCK and keep Winsock error codes in $!. This is indeed apparently the most obvious solution, and was actually Therefore, a follow-up commit However, this resulted in compatibility problems with other libraries. This is why it was decided to jump the other way instead, changing the So to me the solution here is not at all obvious: * We have tried redefining Exxx constants to WSAExxx values, but that * We have tried not redefining any Exxx constants, but that requires Regarding the first attempt, there is the further possibility that we The other idea (raised further below) is to restore Winsock error Can you think of any other solution here?
(This is covered by my comments above regarding our first attempt at a
Yes, absolutely. As I've written above that's exactly what we we've C:\git\perl>perl -Ilib -MPOSIX -E "$!=POSIX::EWOULDBLOCK; say $!"
Our position in believing it to be safe was that Perl *does* provide I'm sure that if this problem had come to light years ago, such that
Yes, that is true :-/
Yes, indeed. We would certainly have to revert to putting Winsock
(As noted earlier, I think we've tried this both ways now and come
|
From @LeontOn Thu, Mar 19, 2015 at 7:11 PM, Laurent <laurent.aml@gmail.com> wrote:
Maybe I'm saying something stupid here, but I would expect $! to do the Leon |
From @steve-m-hayOn 20 March 2015 at 10:00, Leon Timmermans <fawaka@gmail.com> wrote:
Not a stupid thing to say at all. Perl functions wrapping CRT The same page also notes that, "early versions of Windows (Windows 95 This may explain why WSAGetLastError() codes have long been put into In retrospect it's easy to say that it would probably have made more I don't know where this all leaves us in our need to sort out |
From laurent.aml@gmail.comSteve, On Thu, Mar 19, 2015 at 8:18 PM, Steve Hay <steve.m.hay@googlemail.com>
I am not convinced the backward compatibility breakage was sufficiently Also, the supposition that everyone would use EWOULDBLOCK for winsock [...]
I did so, just to point out something related, not to reinterpret what you
I am not retrospectively judging whether assigning WSA* to E* was a
This is indeed apparently the most obvious solution, and was actually
So that is the obvious solution, and I find reassuring you tested it first.
What was mod_perl returning before (and still does with an older compiler, The issue is wider than that... XS modules compiled with different
With the current situation, Perl versions compiled with different compilers One suggestion is: The above proposal fixes the compatibility issues and the WSA/E Then, I am not sure it would be required to fully split WSA/E codes. At Another solution is to wrap winsock in a Posix abstraction layer: make it Perl is schizophrenic here: it tries to stick to low level interfaces The last solution I see is to give up on the WSA* to E* mapping, which I guess using Perl 5.18 with a compiler without the new E* values is the -- Laurent |
From @steve-m-hayOn 24 March 2015 at 15:43, Laurent <laurent.aml@gmail.com> wrote:
The breakage (in code testing $! against Winsock codes like 10053 It may seem a little strange that new #defines in errno.h have an
mod_perl didn't change in this area. The breakage was caused by the Apache is compiled with no E* constants re#defined from their standard However, mod_perl's XS components are compiled in the presence of perl What has mod_perl done wrong there?! It simply links in Apache library You may point out that Apache are providing different error codes That's why I really don't like re#defining E* constants, which was an By contrast, the second attempt causes no interference in C-level E* I see that it has problems too, but I think they mostly stem back to
This is true. bulk88 already raised the point that different error
Yes, that would break, but normally one puts the error code into
By this I assume you are referring to your 11 Mar comment
Thank you again for these suggestions. My initial thoughts are: - The first solution (putting Winsock codes back into $!) requires - The second solution (creating a better abstraction layer) also - The third solution (dropping all E*/WSA* mappings) would again break I will try to find time to digest these proposals properly, and will
|
From @steve-m-hayOn 24 March 2015 at 15:43, Laurent <laurent.aml@gmail.com> wrote:
I meant to respond to this last night too, but missed it. It's true that nothing in the expected places in perl's documentation Searching through the documentation now, though, I do find one Here's the full section from perl5200delta's Incompatible Change =head2 Assignments of Windows sockets error codes to $! now prefer In previous versions of Perl, Windows sockets error codes as returned by This worked well until VC++ 2010 and later, which introduced new E* constants To avoid this incompatibility, perl now maps WSAE* error codes to E* values In order to avoid breakage in existing Perl code which assigns WSAE* values to However, one backwards-incompatibility remains: existing Perl code which |
From rosiejjjj@outlook.comSteve Hay wrote:
So basically, any .dll compiled with >= VC 2010, which is libc/MS CRT Here is a question, has MS made any comments on why they messed up the My understand is poor, do the Winsock APIs actually return the 100-200
|
From rosiejjjj@outlook.comSteve Hay wrote:
So basically, any .dll compiled with >= VC 2010, which is libc/MS CRT Here is a question, has MS made any comments on why they messed up the My understand is poor, do the Winsock APIs actually return the 100-200
|
From @steve-m-hayOn 26 March 2015 at 09:59, bulk 88 <rosiejjjj@outlook.com> wrote:
MS haven't changed any existing E* constants; they've only added new I've not heard of any cases of Winsock functions using these new E* So I think problems only arise for applications that #define "missing" I doubt if there is any way to fix all the issues with $!/E* that have Users would then have to check I think the confusion in where to put Winsock error codes arises |
From @ap* Steve Hay <steve.m.hay@googlemail.com> [2015-03-25 04:25]:
Note well that solution 3 can equally well serve as a stepping stone to Now, about managing the transition: One thing that occurs to me is that fixing what gets put in $! in and Ideally, might it even be possible to write a compat module loadable on If so, then users would have a clean option to fix their code to work on Meanwhile, over in $! land, the mapping would be put back in, working What to do for XS is a harder issue. It may be that XS code will just Is that feasible? *If* that combination comes together, then a long deprecation could be That way, things that sort-of work now would keep sort-of working for How’s that sound? Regards, |
From @steve-m-hayOn 28 March 2015 at 12:21, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote:
As I wrote in another email
That would certainly make it easier for people to switch to using the
I wouldn't envisage taking the mapping out in the first place (until
|
From @jkeenanOn Thu, 24 Apr 2014 18:15:49 GMT, chorny wrote:
This RT has been open for 2-1/2+ years. According to http://matrix.cpantesters.org/?dist=AnyEvent, AnyEvent version 7.13 is PASSing steadily on mswin32, including, most recently, this report from Chorny, who originally opened this ticket: http://www.cpantesters.org/cpan/report/3ddfe2f2-6bf4-1014-b95a-2450d4098b66 In addition, there was a lot of discussion of other issues in the RT -- discussion not specific to AnyEvent and discussion not resolved. How shall we proceed? Thank you very much.
-- |
From @xsawyerxOn Tue, 06 Dec 2016 14:19:11 -0800, jkeenan wrote:
I think we should resolve this issue and start either a thread or a ticket to continue this discussion. The breakage doesn't exist any longer (considering the test reports), but the greater issue of how to handle these codes (not expressed in the topic of this RT ticket) has yet to be determined. |
From @jkeenanOn Tue, 27 Dec 2016 11:11:47 GMT, xsawyerx@cpan.org wrote:
Accordingly, I'm resolving the ticket. Steve, Aristotle, bulk88, others with an opinion -- please feel free to post on the mailing list something to start the discussion off. (I'd suggest not filing a new perlbug until we have something more specific that needs RT tracking.) Thank you very much. -- |
|
@jkeenan - Status changed from 'open' to 'resolved' |
p5pRT
added
BBC
Migrated from rt.perl.org#121727 (status was 'resolved')
Searchable as RT121727$
The text was updated successfully, but these errors were encountered: