Bleadperl breaks OALDERS/LWP-Protocol-https-6.07.tar.gz on Windows #16418
Comments
From @chornyCreated by @chornyhttps_proxy.t hangs on 5.27.8, did not hang on 5.27.6, 5.27.1, 5.26.0. I'm using Windows XP SP3 Russian 32-bit. Also reported here: libwww-perl/LWP-Protocol-https#52 Perl Info |
From @jkeenanOn Tue, 13 Feb 2018 11:43:20 GMT, chorny wrote:
I see that the test file which is hanging has code in it like this: ##### # child process runs _server and exits ... and as well: ##### 'goto' is cited in commit messages for the following commits in the last 3 months: ##### Are you in a position to build perl at each of these commits and see which is the first in which that test hangs? List: Do people on other versions of Windows also get this hang? Thank you very much. -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From @chorny2018-02-14 16:56 GMT+02:00 James E Keenan via RT <perlbug-followup@perl.org>:
I've done manual bisect. I've used another module that hangs - When installing IO::Socket::SSL, you should install -- |
From @chornyOn Tue, 13 Feb 2018 03:43:20 -0800, chorny wrote:
Similar error is in KAORU/HTTP-Async-0.33.tar.gz (https://rt.cpan.org/Ticket/Display.html?id=125169) -- |
From [Unknown Contact. See original ticket]On Tue, 13 Feb 2018 03:43:20 -0800, chorny wrote:
Similar error is in KAORU/HTTP-Async-0.33.tar.gz (https://rt.cpan.org/Ticket/Display.html?id=125169) -- |
From @jkeenanOn Sat, 21 Apr 2018 22:51:22 GMT, chorny wrote:
It appears that we neglected to add this RT to the list of perl-5.28.0 blockers (RT 127689). I have done so now. These failures appear to be Windows-specific. Just now I used cpanm to successfully install every module listed in this RT on both Linux and FreeBSD-11.1. Thank you very much. |
From @iabynOn Thu, Mar 08, 2018 at 01:06:24AM +0200, Alexandr Ciornii wrote:
Zefram, that commit was one of yours. I don't quite understand the END { kill 9,@childs if @childs }; so perhaps an END block wasn't being called before, or used to be called Do you have any insight? -- |
From @iabynOn Mon, Apr 23, 2018 at 01:39:27PM +0100, Dave Mitchell wrote:
I've now pushed the branch smoke-me/davem/win32_exit, which may fix this. Could someone try it on win32 and see that (a) it doesn't break win32; LWP-Protocol-https-6.0 And ideally confirm my diagnosis that on fork() on win32, END() Here's the commit message: win323 fork(): honour PERL_EXIT_DESTRUCT_END -- |
From @steve-m-hayOn 30 April 2018 at 22:15, Dave Mitchell <davem@iabyn.com> wrote:
Your branch builds and passes all tests for me on Windows 7 with 32-bit VS2015. I've tried out IO::Socket::SSL and find that in blead t/mitm.t hangs D:\Temp\IO-Socket-SSL-2.056-0>perl -Mblib t\session_ticket.t I haven't tried an earlier |
From @steve-m-hayOn 3 May 2018 at 18:20, Steve Hay <steve.m.hay@googlemail.com> wrote:
I've now tried a build of the change prior to So the problem here isn't yet fixed. |
From @iabynOn Fri, May 04, 2018 at 05:58:50PM +0100, Steve Hay via perl5-porters wrote:
What does the following code output under Windows on $| = 1; -- |
From @steve-m-hayOn 4 May 2018 at 20:39, Dave Mitchell <davem@iabyn.com> wrote:
They all output: END: parent |
From @iabynOn Fri, May 04, 2018 at 09:36:17PM +0100, Steve Hay via perl5-porters wrote:
Hmmm. Could you show the output from the attached script for each of the perls -- |
From @iabyn#!/usr/bin/perl use warnings; my ($pid, @pid); END { $pid = fork; push @pid, $pid; |
From @steve-m-hayOn 8 May 2018 at 14:27, Dave Mitchell <davem@iabyn.com> wrote:
Pre-8e920bd341 outputs this: parent: sleep(4) Blead and your branch both output this: parent: sleep(4) |
From @iabynOn Tue, May 08, 2018 at 05:57:10PM +0100, Steve Hay via perl5-porters wrote:
Thanks for that, I finally know what's going on. TL;DR: a can of worms has been opened, and for 5.28 we should close Long form: As I mentioned earlier in this thread, the main() function on UNIXYy PL_exit_flags |= PERL_EXIT_DESTRUCT_END; Setting the PERL_EXIT_DESTRUCT_END flag moves the calling of END blocks Zefram's 8e920bd commit merely set the PERL_EXIT_DESTRUCT_END flag on However, calling END blocks isn't *quite* the first thing in /* wait for all pseudo-forked children to finish */ so by setting PERL_EXIT_DESTRUCT_END, we've moved the calling of It so happens that of the failing distributions and tests that I looked END { kill 9, @child_pids } Now on win32, the END block won't get called until after the children have The fix may well be to move PERL_WAIT_FOR_CHILDREN to after There are also wider issues. For example, one of the short bits of code We need to look at all the cases and decide whether and when END blocks BEGIN { die } -- |
From @iabynOn Wed, May 09, 2018 at 09:48:27AM +0100, Dave Mitchell wrote:
One final favour, Steve: Could you run blead with 8e920bd Thanks. -- |
From @steve-m-hayOn 9 May 2018 at 11:04, Dave Mitchell <davem@iabyn.com> wrote:
Current blead with 8e920bd reverted |
From @steve-m-hay# Failed test 10 - BEGIN{exit 1} should exit at ./test.pl line 1062 Test Summary Report op/blocks.t (Wstat: 0 Tests: 22 Failed: 6) |
From @iabynOn Wed, May 09, 2018 at 01:15:47PM +0100, Steve Hay via perl5-porters wrote:
Thanks. I've just pushed smoke-me/davem/win32_exit_revert which contains -- |
From @xsawyerxOn 05/09/2018 11:48 AM, Dave Mitchell wrote:
Thank you, Dave. We should apply the fix that does this.
|
From @steve-m-hayOn 9 May 2018 at 14:20, Dave Mitchell <davem@iabyn.com> wrote:
This passes (or skips...) all tests for me. |
From @iabynOn Thu, May 10, 2018 at 06:03:40PM +0100, Steve Hay via perl5-porters wrote:
Now merged as v5.27.11-38-g64a9c78095. -- |
From @jkeenanOn Fri, 11 May 2018 07:46:14 GMT, davem wrote:
OP reports that problem was fixed in perl-5.28. See: Resolving ticket. -- |
|
@jkeenan - Status changed from 'open' to 'resolved' |
p5pRT
added
BBC
…struct See #16418 This should fix the issue with Win32.
…struct See #16418 This should fix the issue with Win32.
…struct See #16418 This should fix the issue with Win32.
…struct See Perl#16418 This should fix the issue with Win32.
Migrated from rt.perl.org#132863 (status was 'resolved')
Searchable as RT132863$
The text was updated successfully, but these errors were encountered: