On Fri, Aug 10, 2018 at 12:43 PM William A Rowe Jr wrote:
>
> On Thu, Aug 9, 2018 at 1:06 PM, Eric Covener wrote:
>>
>> On Thu, Aug 9, 2018 at 11:02 AM Jim Jagielski wrote:
>> >
>> > Anyone having issues w/ the above test hanging after test 182?
>> >
>> > On the 2.4.x branch it runs thru to
On Thu, Aug 9, 2018 at 1:06 PM, Eric Covener wrote:
> On Thu, Aug 9, 2018 at 11:02 AM Jim Jagielski wrote:
> >
> > Anyone having issues w/ the above test hanging after test 182?
> >
> > On the 2.4.x branch it runs thru to completion, but on trunk (macOS),
> > stalls after 182:
>
> For me on
On Fri, Aug 10, 2018 at 6:28 PM, Jim Jagielski wrote:
> even more so w/ r1837823 :)
Great, thanks for testing!
even more so w/ r1837823 :)
thx
> On Aug 10, 2018, at 12:19 PM, Yann Ylavic wrote:
>
> On Fri, Aug 10, 2018 at 3:40 PM, Jim Jagielski wrote:
>> Looks like some looping (full error log at:
>> http://home.apache.org/~jim/test/error_log)
>
> Better with r1837822?
On Fri, Aug 10, 2018 at 3:40 PM, Jim Jagielski wrote:
> Looks like some looping (full error log at:
> http://home.apache.org/~jim/test/error_log)
Better with r1837822?
Looks like some looping (full error log at:
http://home.apache.org/~jim/test/error_log)
[Fri Aug 10 13:36:09.607977 2018] [core:trace8] [pid 43559:tid 123145562525696]
util_filter.c(935): [client 127.0.0.1:63911] brigade contains: bytes: 0,
non-file bytes: 0, eor buckets: 1, morphing buckets:
I've just been able to test on macOS lately. Will work on getting you the
requested error info. Thx
> On Aug 10, 2018, at 9:15 AM, Yann Ylavic wrote:
>
> On Thu, Aug 9, 2018 at 10:10 PM, Jim Jagielski wrote:
>> I had to go all the way back to r1835846 to get trunk stable again...
>> r1836239
On Thu, Aug 9, 2018 at 10:10 PM, Jim Jagielski wrote:
> I had to go all the way back to r1835846 to get trunk stable again...
> r1836239 is the start of the breakage... :<
Thanks for bisecting, does it happen on OSX only or other platforms
too? (can't reproduce on my side...)
An errog_log with
Yeppers... looks like:
core: axe data_in_in/output_filter from conn_rec.
was done prematurely and/or not completely.
Yann, can you fix this? I'm having a hard time groking your thought process in
the restructuring here.
> On Aug 9, 2018, at 4:10 PM, Jim Jagielski wrote:
>
> I had to go
I had to go all the way back to r1835846 to get trunk stable again...
r1836239 is the start of the breakage... :<
> On Aug 9, 2018, at 3:59 PM, Jim Jagielski wrote:
>
> I've confirmed that this does NOT happen w/ worker or prefork, so it's
> definitely something broken with the recent churn
I've confirmed that this does NOT happen w/ worker or prefork, so it's
definitely something broken with the recent churn on the Event MPM.
No doubt, stuff done over the last 2-3 weeks have broken Event.
Hmmm... 2.4 runs clean, but it did take some time to come up with
a Perl environment that didn't barf... Mostly, I had to use a really old
Perl. Here it is:
/opt/perl5/bin/perl -V
Summary of my perl5 (revision 5 version 20 subversion 3) configuration:
Platform:
osname=darwin,
On Thu, Aug 9, 2018 at 11:02 AM Jim Jagielski wrote:
>
> Anyone having issues w/ the above test hanging after test 182?
>
> On the 2.4.x branch it runs thru to completion, but on trunk (macOS),
> stalls after 182:
For me on trunk at least (2.4 sandbox is unhealthy) it seems to hang
in different
On Thu, Aug 9, 2018 at 1:44 PM Eric Covener wrote:
>
> On Thu, Aug 9, 2018 at 11:02 AM Jim Jagielski wrote:
> >
> > Anyone having issues w/ the above test hanging after test 182?
> >
> > On the 2.4.x branch it runs thru to completion, but on trunk (macOS),
> > stalls after 182:
>
> Seems to be
On Thu, Aug 9, 2018 at 11:02 AM Jim Jagielski wrote:
>
> Anyone having issues w/ the above test hanging after test 182?
>
> On the 2.4.x branch it runs thru to completion, but on trunk (macOS),
> stalls after 182:
Seems to be skipped for me, haven't dug into the verify thing yet if
you happen to
Anyone having issues w/ the above test hanging after test 182?
On the 2.4.x branch it runs thru to completion, but on trunk (macOS),
stalls after 182:
...
#lwp request:
#GET http://localhost:8529/getfiles-perl-pod/perlxstypemap.pod HTTP/1.1
#User-Agent: libwww-perl/6.26
#
On Tue, 4 Dec 2001, Doug MacEachern wrote:
On Thu, 22 Nov 2001, Stas Bekman wrote:
I can extend it to engulf the plan() extension that we have added and then
the only function you will ever call with plan() is skip_unless. I
think this:
plan ..., skip_unless('cgi', 'lwp');
there's
On Fri, 21 Dec 2001, Stas Bekman wrote:
OK, here it is: I've finally called it skip_all() as it's a standalone
function now.
cool, +1. but would rather it still be called skip_unless()
ebinc wrote:
Does any one know how to unsubscribe from this list? Ive been
on the site but cannot find were it is
In the mail header you'll see:
list-unsubscribe: mailto:[EMAIL PROTECTED]
which is the Sum of All Wisdom for this question. :-)
--
#kenP-)}
Ken Coar,
Doug MacEachern wrote:
On Thu, 22 Nov 2001, Stas Bekman wrote:
I can extend it to engulf the plan() extension that we have added and then
the only function you will ever call with plan() is skip_unless. I
think this:
plan ..., skip_unless('cgi', 'lwp');
there's no point in overloading plan
On Wed, 5 Dec 2001, Stas Bekman wrote:
I didn't get you? do you prefer to make this change and disengage skip
stuff from plan:
skip_unless(...);
plan tests = $tests;
i'd like it if the current shorthand continues to work:
plan tests = $tests, ['lwp', 'cgi'];
i would not like it if
Doug MacEachern wrote:
On Wed, 5 Dec 2001, Stas Bekman wrote:
I didn't get you? do you prefer to make this change and disengage skip
stuff from plan:
skip_unless(...);
plan tests = $tests;
i'd like it if the current shorthand continues to work:
plan tests = $tests, ['lwp', 'cgi'];
i would
22 matches
Mail list logo
