Re: release anyone?

[Rainer Jung]

Am 25.05.2022 um 14:15 schrieb Stefan Eissing:

Anyone feeling release vibes in the air?

it's been a good 2.5 months and some things have accumulated.
Maybe the start of June would be a good target?


+1 and thanks!

Rainer

Re: release anyone?

[Ruediger Pluem]

On 5/25/22 2:15 PM, Stefan Eissing wrote:
> Anyone feeling release vibes in the air? 
> 
> it's been a good 2.5 months and some things have accumulated. 
> Maybe the start of June would be a good target?

+1

Regards

Rüdiger

Re: release anyone?

[Yann Ylavic]

On Wed, May 25, 2022 at 2:15 PM Stefan Eissing  wrote:
>
> Anyone feeling release vibes in the air?

+1 thanks for proposing!

Re: release anyone?

[Eric Covener]

+1 ty!

On Wed, May 25, 2022, 8:15 AM Stefan Eissing  wrote:

> Anyone feeling release vibes in the air?
>
> it's been a good 2.5 months and some things have accumulated.
> Maybe the start of June would be a good target?
>
> Kind Regards,
> Stefan
>

Re: release vibes?

[Ruediger Pluem]

On 2/8/22 12:20 PM, Eric Covener wrote:
> On Tue, Feb 8, 2022 at 4:43 AM Stefan Eissing  wrote:
>>
>> Is there any consensus in doing a release this month?
> +1
> 

+1. There is one backport for mod_dav that misses 1 vote. Who is brave enough 
to backport the PCRE stuff that is accepted for
backport?

Regards

Rüdiger

Re: release vibes?

[Eric Covener]

On Tue, Feb 8, 2022 at 4:43 AM Stefan Eissing  wrote:
>
> Is there any consensus in doing a release this month?
+1

Re: release vibes?

[Nick Edwards]

Release often?  let me tell you of a story from a System Administrators
perspective as to why thats bad and should be avoided and you should learn
from other people's mistakes

There is a reason sysads dislike developers, they have this "oh new code
gotta push it out right away" mentality, but we push back saying nope we
just did your upgrade it can wait will another one, and the golden rule is
nobody updates anything during the christmas "embargo" period which I
believe Noel was referring to, this generally is from two weeks before
Christmas, til two weeks after the start of the New Year.

There was once this young guy who developed this shiny new yet highly
popular internet daemon, in its infancy it was a wizzbang and everybody
loved it and was moving to it, the problem soon arose that every new
feature was pushed out, and as murphy dictates, problem be found, sometimes
sysads were having to update this highly popular software every few weeks,
sometimes more, there was even a few times we recall having to update it
three times in just ONE week because of this push push push mentality, this
results in a large percentage of sysads pushing back and refusing to test
let alone update, over time this continued, new releases every few weeks,
tiresome - like we have nothing better to do but upgrade the same software
over and over and over, wasn't going to happen, and didn't happen, some of
these were to fix nasty exploitable problems, but almost nobody bothered
because "jesus christ another bloody update"... a lot of people were burned.

That same project did get a lot better with a rewrite of its code and a
move to a new "major release" the updates still came, but not thick and
fast, this made sysads much happier, the developer had learned push often
is not what system and network operators want, now days sysads love that
project, it releases every few months on average which we can accept and
has much fewer bugs, and rarely anything severe.

That project, is called   dovecot



On Wed, Dec 8, 2021 at 1:17 AM Mladen Turk  wrote:

>
>
> On 06/12/2021 11:36, Stefan Eissing wrote:
> > Friends of httpd, how do you feel about a release in the next two weeks?
> >
>
> +1
> Release early, release often
>
> Regards
> --
> ^TM
>

Re: release vibes?

[Giovanni Bechis]

On 12/8/21 13:56, Joe Orton wrote:
> On Mon, Dec 06, 2021 at 11:36:51AM +0100, Stefan Eissing wrote:
>> Friends of httpd, how do you feel about a release in the next two weeks?
> 
> Sounds good to me. We may have fewer people around to test it, but at 
> least trying to get a release out is better than definitely having no 
> release IMO.
> 
+1
let's try to cook a release.
 Giovanni



OpenPGP_signature
Description: OpenPGP digital signature

Re: release vibes?

[Stefan Eissing]

> Am 08.12.2021 um 13:56 schrieb Joe Orton :
> 
> On Mon, Dec 06, 2021 at 11:36:51AM +0100, Stefan Eissing wrote:
>> Friends of httpd, how do you feel about a release in the next two weeks?
> 
> Sounds good to me. We may have fewer people around to test it, but at 
> least trying to get a release out is better than definitely having no 
> release IMO.

Excellent. I propose targeting Tuesday 14th for a candidate. If
we go later, it becomes very close to the holidays. But if the time is
needed, we can do that as well.

I will hold back the current http2 backport, as I need some more people
to dare test that from the github on their sites.

The mod_tls acceptance I understood as we would like to include that
as experimental in the next 2.4.x release. If there are no objections,
I will prepare that.

Kind Regards,
Stefan

> 
> Regards, Joe
> 

Re: release vibes?

[Joe Orton]

On Mon, Dec 06, 2021 at 11:36:51AM +0100, Stefan Eissing wrote:
> Friends of httpd, how do you feel about a release in the next two weeks?

Sounds good to me. We may have fewer people around to test it, but at 
least trying to get a release out is better than definitely having no 
release IMO.

Regards, Joe

Re: release vibes?

[Noel Butler]

On 08/12/2021 01:14, Mladen Turk wrote:

On 06/12/2021 12:27, Noel Butler wrote: On 06/12/2021 20:36, Stefan 
Eissing wrote:


Friends of httpd, how do you feel about a release in the next two 
weeks?


Kind Regards,
Stefan
-1

Thats days before christmas, most testers and i'm sure devs will be in 
holiday mode, even if not, that close to christmas means server updates 
are in embargo status in most organisations.


Probably the worst -1 reason ever.

Regards

really? so, who is going to test for bugs, just the handful of code 
submitters?


so us non PMC testers are not needed, cool, cya :)

--
Regards,
Noel Butler

This Email, including attachments, may contain legally privileged 
information, therefore at all times remains confidential and subject to 
copyright protected under international law. You may not disseminate 
this message without the authors express written authority to do so.   
If you are not the intended recipient, please notify the sender then 
delete all copies of this message including attachments immediately. 
Confidentiality, copyright, and legal privilege are not waived or lost 
by reason of the mistaken delivery of this message.

Re: release vibes?

[Mladen Turk]

On 07/12/2021 16:16, Mladen Turk wrote:



On 06/12/2021 11:36, Stefan Eissing wrote:

Friends of httpd, how do you feel about a release in the next two weeks?



+1
Release early, release often



Anyhow, who I'm I to say, not even metinioned on
https://httpd.apache.org/contributors/


Regards
--
^TM

Re: release vibes?

[Mladen Turk]

On 06/12/2021 11:36, Stefan Eissing wrote:

Friends of httpd, how do you feel about a release in the next two weeks?



+1
Release early, release often

Regards
--
^TM

Re: release vibes?

[Mladen Turk]

On 06/12/2021 12:27, Noel Butler wrote:

On 06/12/2021 20:36, Stefan Eissing wrote:


Friends of httpd, how do you feel about a release in the next two weeks?

Kind Regards,
Stefan


-1

Thats days before christmas, most testers and i'm sure devs will be in 
holiday mode, even if not, that close to christmas means server updates 
are in embargo status in most organisations.





Probably the worst -1 reason ever.



Regards
--
^TM

Re: release vibes?

[Noel Butler]

On 06/12/2021 20:36, Stefan Eissing wrote:

Friends of httpd, how do you feel about a release in the next two 
weeks?


Kind Regards,
Stefan


-1

Thats days before christmas, most testers and i'm sure devs will be in 
holiday mode, even if not, that close to christmas means server updates 
are in embargo status in most organisations.


--
Regards,
Noel Butler

This Email, including attachments, may contain legally privileged 
information, therefore at all times remains confidential and subject to 
copyright protected under international law. You may not disseminate 
this message without the authors express written authority to do so.   
If you are not the intended recipient, please notify the sender then 
delete all copies of this message including attachments immediately. 
Confidentiality, copyright, and legal privilege are not waived or lost 
by reason of the mistaken delivery of this message.

Re: release roll soon?

[Yann Ylavic]

On Fri, Sep 10, 2021 at 4:33 PM ste...@eissing.org  wrote:
>
> Found https://bz.apache.org/bugzilla/show_bug.cgi?id=64753
>
> Switch the configure.in to the one in branches/1.7.x, buildconf again and now 
> it compiles

The checked in patch seems to be https://svn.apache.org/r1871981

>
> Seems, a new APR release would be nice for the poor macOS people...

On its way, AIUI.

Cheers;
Yann.

Re: release roll soon?

[ste...@eissing.org]

> Am 10.09.2021 um 16:31 schrieb Yann Ylavic :
> 
> On Fri, Sep 10, 2021 at 4:18 PM ste...@eissing.org  wrote:
>> 
>> APR experts: I build the -deps tar with apr 1.7.0 / apr-util 1.6.1. Those 
>> are looked up at the site as the latest, just like the old scripts did.
>> However, that will not configure on my macOS. The branches/1.7.x which I 
>> normally use does.
>> 
>> ./include/apr.h:561:2: error: Can not determine the proper size for pid_t
>> 
>> any one can help my poor memory on how to work around that?
> 
> You could test the non-deps tarball and have your usual 1.7.x checkout
> in srclib?
> The -deps are only provided for convenience, in this case it simply
> does not help macOS users.
> If you want to email me with the tarball I can smoke test it on linux at 
> least.

Found https://bz.apache.org/bugzilla/show_bug.cgi?id=64753

Switch the configure.in to the one in branches/1.7.x, buildconf again and now 
it compiles

Seems, a new APR release would be nice for the poor macOS people...
> 
>> 
>> I have the insane plan to actually test the tars before putting them out for 
>> voting...
> 
> That'll teach you..

I learn so much from my mistakes, I just make some more!

> 
> 
> Cheers;
> Yann.

Re: release roll soon?

[Yann Ylavic]

On Fri, Sep 10, 2021 at 4:18 PM ste...@eissing.org  wrote:
>
> APR experts: I build the -deps tar with apr 1.7.0 / apr-util 1.6.1. Those are 
> looked up at the site as the latest, just like the old scripts did.
> However, that will not configure on my macOS. The branches/1.7.x which I 
> normally use does.
>
> ./include/apr.h:561:2: error: Can not determine the proper size for pid_t
>
> any one can help my poor memory on how to work around that?

You could test the non-deps tarball and have your usual 1.7.x checkout
in srclib?
The -deps are only provided for convenience, in this case it simply
does not help macOS users.
If you want to email me with the tarball I can smoke test it on linux at least.

>
> I have the insane plan to actually test the tars before putting them out for 
> voting...

That'll teach you..


Cheers;
Yann.

Re: release roll soon?

[ste...@eissing.org]

APR experts: I build the -deps tar with apr 1.7.0 / apr-util 1.6.1. Those are 
looked up at the site as the latest, just like the old scripts did.
However, that will not configure on my macOS. The branches/1.7.x which I 
normally use does.

./include/apr.h:561:2: error: Can not determine the proper size for pid_t

any one can help my poor memory on how to work around that?

I have the insane plan to actually test the tars before putting them out for 
voting...

- Stefan

> Am 10.09.2021 um 12:12 schrieb Ruediger Pluem :
> 
> 
> 
> On 9/10/21 12:07 PM, ste...@eissing.org wrote:
>> 
> 
>> So far, I hear that people think we should make a 2.4.49 based 
>> on the current 2.4.x. 
>> 
>> I will do some IRL errands and things and come back to this 
>> in the afternoon. If this still stands then, I'll create a 
>> 2.4.49-rc1 and put that to the vote.
>> 
> 
> Sounds good. Thanks for all your work on this and especially on the scripting.
> 
> Regards
> 
> Rüdiger

Re: release roll soon?

[Ruediger Pluem]

On 9/10/21 12:07 PM, ste...@eissing.org wrote:
> 

> So far, I hear that people think we should make a 2.4.49 based 
> on the current 2.4.x. 
> 
> I will do some IRL errands and things and come back to this 
> in the afternoon. If this still stands then, I'll create a 
> 2.4.49-rc1 and put that to the vote.
> 

Sounds good. Thanks for all your work on this and especially on the scripting.

Regards

Rüdiger

Re: release roll soon?

[ste...@eissing.org]

> Am 10.09.2021 um 11:07 schrieb Ruediger Pluem :
> 
> 
> 
> On 9/10/21 10:50 AM, Joe Orton wrote:
>> On Fri, Sep 10, 2021 at 09:42:10AM +0200, ste...@eissing.org wrote:
>>> 
>>> 
 Am 10.09.2021 um 09:02 schrieb Joe Orton :
 
 On Thu, Sep 09, 2021 at 03:23:13PM -0700, Gregg Smith wrote:
> Since OpenSSL 3.0.0 GA came out yesterday (Californuts time) I think it
> would be nice to have r1891138 backported for those wishing to try it out.
> What you say?
 
 I'd say it's better to try to get a successful release out, then try to 
 get new features in the stable branch.  (In fact, I'd be quite happy if 
 we had 2.5.x/2.6 released and stopped trying new features in 2.4 :)
 
 That revision is not sufficient, I have a hopefully-complete set of 
 OpenSSL 3.0 backports at: https://github.com/apache/httpd/pull/258
>>> 
>>> Do you want that in 2.4.49? (we can always to a 2.4.50 OpenSSL3 
>>> release shortly afterwards, imo)
>> 
>> For me, I'd not want to delay or risk regressions in .49 for this, it's 
>> only a small niche of users who care about it at the moment.  I plan to 
>> propose the PR for backport after the next release.
> 
> +1
> 
>> 
>> (It'd be nice to get 3.0 building in Travis so we can be more confident 
>> about keeping that working, not sure if anybody is testing trunk against 
>> it regularly right now?)
> 
> +1

So far, I hear that people think we should make a 2.4.49 based 
on the current 2.4.x. 

I will do some IRL errands and things and come back to this 
in the afternoon. If this still stands then, I'll create a 
2.4.49-rc1 and put that to the vote.

cheers,
Stefan

Re: release roll soon?

[Ruediger Pluem]

On 9/10/21 10:50 AM, Joe Orton wrote:
> On Fri, Sep 10, 2021 at 09:42:10AM +0200, ste...@eissing.org wrote:
>>
>>
>>> Am 10.09.2021 um 09:02 schrieb Joe Orton :
>>>
>>> On Thu, Sep 09, 2021 at 03:23:13PM -0700, Gregg Smith wrote:
 Since OpenSSL 3.0.0 GA came out yesterday (Californuts time) I think it
 would be nice to have r1891138 backported for those wishing to try it out.
 What you say?
>>>
>>> I'd say it's better to try to get a successful release out, then try to 
>>> get new features in the stable branch.  (In fact, I'd be quite happy if 
>>> we had 2.5.x/2.6 released and stopped trying new features in 2.4 :)
>>>
>>> That revision is not sufficient, I have a hopefully-complete set of 
>>> OpenSSL 3.0 backports at: https://github.com/apache/httpd/pull/258
>>
>> Do you want that in 2.4.49? (we can always to a 2.4.50 OpenSSL3 
>> release shortly afterwards, imo)
> 
> For me, I'd not want to delay or risk regressions in .49 for this, it's 
> only a small niche of users who care about it at the moment.  I plan to 
> propose the PR for backport after the next release.

+1

> 
> (It'd be nice to get 3.0 building in Travis so we can be more confident 
> about keeping that working, not sure if anybody is testing trunk against 
> it regularly right now?)

+1

Regards

Rüdiger

Re: release roll soon?

[Joe Orton]

On Fri, Sep 10, 2021 at 09:42:10AM +0200, ste...@eissing.org wrote:
> 
> 
> > Am 10.09.2021 um 09:02 schrieb Joe Orton :
> > 
> > On Thu, Sep 09, 2021 at 03:23:13PM -0700, Gregg Smith wrote:
> >> Since OpenSSL 3.0.0 GA came out yesterday (Californuts time) I think it
> >> would be nice to have r1891138 backported for those wishing to try it out.
> >> What you say?
> > 
> > I'd say it's better to try to get a successful release out, then try to 
> > get new features in the stable branch.  (In fact, I'd be quite happy if 
> > we had 2.5.x/2.6 released and stopped trying new features in 2.4 :)
> > 
> > That revision is not sufficient, I have a hopefully-complete set of 
> > OpenSSL 3.0 backports at: https://github.com/apache/httpd/pull/258
> 
> Do you want that in 2.4.49? (we can always to a 2.4.50 OpenSSL3 
> release shortly afterwards, imo)

For me, I'd not want to delay or risk regressions in .49 for this, it's 
only a small niche of users who care about it at the moment.  I plan to 
propose the PR for backport after the next release.

(It'd be nice to get 3.0 building in Travis so we can be more confident 
about keeping that working, not sure if anybody is testing trunk against 
it regularly right now?)

Regards, Joe

Re: release roll soon?

[Daniel Ferradal]

Indeed it kind of sounds too early to go with OpenSSL 3 yet to consider for
a stable release of apache. (Too fresh out of the oven?)


El vie., 10 sept. 2021 9:42, ste...@eissing.org 
escribió:

>
>
> > Am 10.09.2021 um 09:02 schrieb Joe Orton :
> >
> > On Thu, Sep 09, 2021 at 03:23:13PM -0700, Gregg Smith wrote:
> >> Since OpenSSL 3.0.0 GA came out yesterday (Californuts time) I think it
> >> would be nice to have r1891138 backported for those wishing to try it
> out.
> >> What you say?
> >
> > I'd say it's better to try to get a successful release out, then try to
> > get new features in the stable branch.  (In fact, I'd be quite happy if
> > we had 2.5.x/2.6 released and stopped trying new features in 2.4 :)
> >
> > That revision is not sufficient, I have a hopefully-complete set of
> > OpenSSL 3.0 backports at: https://github.com/apache/httpd/pull/258
>
> Do you want that in 2.4.49? (we can always to a 2.4.50 OpenSSL3 release
> shortly afterwards, imo)
>
> - Stefan

Re: release roll soon?

[ste...@eissing.org]

> Am 10.09.2021 um 09:02 schrieb Joe Orton :
> 
> On Thu, Sep 09, 2021 at 03:23:13PM -0700, Gregg Smith wrote:
>> Since OpenSSL 3.0.0 GA came out yesterday (Californuts time) I think it
>> would be nice to have r1891138 backported for those wishing to try it out.
>> What you say?
> 
> I'd say it's better to try to get a successful release out, then try to 
> get new features in the stable branch.  (In fact, I'd be quite happy if 
> we had 2.5.x/2.6 released and stopped trying new features in 2.4 :)
> 
> That revision is not sufficient, I have a hopefully-complete set of 
> OpenSSL 3.0 backports at: https://github.com/apache/httpd/pull/258

Do you want that in 2.4.49? (we can always to a 2.4.50 OpenSSL3 release shortly 
afterwards, imo)

- Stefan

Re: release roll soon?

[Joe Orton]

On Thu, Sep 09, 2021 at 03:23:13PM -0700, Gregg Smith wrote:
> Since OpenSSL 3.0.0 GA came out yesterday (Californuts time) I think it
> would be nice to have r1891138 backported for those wishing to try it out.
> What you say?

I'd say it's better to try to get a successful release out, then try to 
get new features in the stable branch.  (In fact, I'd be quite happy if 
we had 2.5.x/2.6 released and stopped trying new features in 2.4 :)

That revision is not sufficient, I have a hopefully-complete set of 
OpenSSL 3.0 backports at: https://github.com/apache/httpd/pull/258

Regards, Joe

Re: release roll soon?

[Mario Brandt]

On Thu, 9 Sept 2021 at 22:23, Gregg Smith  wrote:
>
> Since OpenSSL 3.0.0 GA came out yesterday (Californuts time) I think it
> would be nice to have r1891138 backported for those wishing to try it
> out. What you say?

+1 for the backport

Re: release roll soon?

[Dennis Clarke]

On 9/9/21 18:23, Gregg Smith wrote:
> Since OpenSSL 3.0.0 GA came out yesterday (Californuts time) I think it
> would be nice to have r1891138 backported for those wishing to try it
> out. What you say?

I have been doing some testing with the OpenSSL beta releases for quite
some time now. However recently my Apache trunk builds have been running
into problems with autotools and basic configuration steps. I may reach
out to the maillist regarding that.



-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

Re: release roll soon?

[Gregg Smith]

Since OpenSSL 3.0.0 GA came out yesterday (Californuts time) I think it 
would be nice to have r1891138 backported for those wishing to try it 
out. What you say?


Cheers,

Gregg

Re: release roll soon?

[Yann Ylavic]

On Thu, Sep 9, 2021 at 4:11 PM ste...@eissing.org  wrote:
>
> FYI: from the script side, I am ready to roll the first candidate.
> - We have one security issue in a not quite complete state
> - There are 2 possible back ports hanging in STATUS
>
> We can see tomorrow how comfy we are and either I roll right away or
> we target Monday/Tuesday, I suppose.

+1, works either way for me.

Re: release scripts

[Yann Ylavic]

Awesome, great work Stefan, thanks a lot!

On Tue, Sep 7, 2021 at 4:22 PM ste...@eissing.org  wrote:
>
> After some learning experience (*cough*) I committed a new
> version of the scripts, now in $DEV_TOOLS/release that go
> so far as staging local changes to all repositories after
> a successful vote.
>
> I will test some more tomorrow and add the announce mailing
> part. The real test will then come when actually doing a
> release as testing is hard to cover all code paths otherwise.
>
> I have silently sneaked in - as some fringe benefit to all
> the pain - a '-rcN' suffix for vote candidates. Since we
> will be able to cancel a release much later now without
> modifying a source repository.
>
> The -rcN tars for voting are named as such, but the directories
> contained have the version without any suffix. So, a -rcN
> tar can be renamed to the release tar without changes when
> the vote has passed.
>
>
> Cheers, Stefan

Re: release?

[ste...@eissing.org]

The v2 release scripts in ^/httpd/dev-tools do now work for me
to create the tarballs, checksums and signatures for a release
vote and push them to dist.apache.org.

The steps after a vote need some more work. I will do that in the
coming days. However, since we can do a vote now, this is not that
pressing.

The "announce.sh" part should stay usable as it is. I have no plans 
to update that one, since I have 0 experience what this really does 
and where any problems/room for improvements are.

Cheers,
Stefan


> Am 02.09.2021 um 16:53 schrieb Ruediger Pluem :
> 
> 
> 
> On 9/2/21 3:06 PM, Eric Covener wrote:
>> Since you are going through this I wanted to mention:
>> 
>> I think the public doc we have should mention everything that's done
>> during ther release, even the security stuff that is somewhat private.
>> The ASF-wide security policy is already public
>> (https://www.apache.org/security/committers.html) and this is just the
>> mechanics of it for us.
>> 
>> Anyone object?  This way we have one linear place to point to.
> 
> +1 Looks sensible. The details of an actual security issue should not be 
> public until we make it so, but the procedure we use can be.
> 
> Regards
> 
> Rüdiger
> 

Re: release?

[Ruediger Pluem]

On 9/2/21 3:06 PM, Eric Covener wrote:
> Since you are going through this I wanted to mention:
> 
> I think the public doc we have should mention everything that's done
> during ther release, even the security stuff that is somewhat private.
> The ASF-wide security policy is already public
> (https://www.apache.org/security/committers.html) and this is just the
> mechanics of it for us.
> 
> Anyone object?  This way we have one linear place to point to.

+1 Looks sensible. The details of an actual security issue should not be public 
until we make it so, but the procedure we use can be.

Regards

Rüdiger

Re: release?

[Eric Covener]

Since you are going through this I wanted to mention:

I think the public doc we have should mention everything that's done
during ther release, even the security stuff that is somewhat private.
The ASF-wide security policy is already public
(https://www.apache.org/security/committers.html) and this is just the
mechanics of it for us.

Anyone object?  This way we have one linear place to point to.

On Mon, Aug 30, 2021 at 7:36 AM ste...@eissing.org  wrote:
>
> In what state is our release handling? Given someone holding my hand, could I 
> do it? Or is it better to look someone over the shoulder while he does it?
>
> Cheers,
> Stefan



-- 
Eric Covener
cove...@gmail.com

Re: release scripts

[Eric Covener]

On Thu, Sep 2, 2021 at 8:21 AM ste...@eissing.org  wrote:
>
> OK, small hickup. The build shell for the manuals wants a JDK 1.8 or 11...
> uhm...I need a time machine, or we can change the check there.
>
> Since I am not experienced in our manual stuff, can someone knowledgable 
> check this?

If it doesn't create a crazy diff from what's currently generated,
it's fine. Maybe time to strip out the check.

Re: release scripts

[ste...@eissing.org]

OK, small hickup. The build shell for the manuals wants a JDK 1.8 or 11...
uhm...I need a time machine, or we can change the check there.

Since I am not experienced in our manual stuff, can someone knowledgable check 
this?

- Stefan

> Am 01.09.2021 um 13:27 schrieb ste...@eissing.org:
> 
> 
> 
>> Am 01.09.2021 um 13:15 schrieb Eric Covener :
>> 
>> On Wed, Sep 1, 2021 at 6:08 AM ste...@eissing.org  wrote:
>>> 
>>> Having a look at the release scripts and how they work.
>>> 
>>> I think we can use SVN and its branches/tags in a bit smarter way
>>> and make things easier. As Christophe mentioned, he would like a
>>> "--dry-run" option, because when things do not run smoothly to the
>>> end, you have not only a local messed-up state but the SVN repro
>>> itself is also changed without easy remedies.
>> 
>> LGTM. Maybe even separate -tmp and -candidate branches aren't needed?
> 
> We can do without, yes. Seems more simple that way.
> 
>> It's all scratch space for the RM.
>> Does the release branch get moved to a tag at the end?
> 
> Yes, that line was missing, I saw too late and did not
> want to add another mail to my wall of text. So
> 
>> svn mv branches/2.4.49-candidate tags/2.4.49
> 
> would be the last thing at the voting.

Re: release scripts

[ste...@eissing.org]

> Am 01.09.2021 um 13:15 schrieb Eric Covener :
> 
> On Wed, Sep 1, 2021 at 6:08 AM ste...@eissing.org  wrote:
>> 
>> Having a look at the release scripts and how they work.
>> 
>> I think we can use SVN and its branches/tags in a bit smarter way
>> and make things easier. As Christophe mentioned, he would like a
>> "--dry-run" option, because when things do not run smoothly to the
>> end, you have not only a local messed-up state but the SVN repro
>> itself is also changed without easy remedies.
> 
> LGTM. Maybe even separate -tmp and -candidate branches aren't needed?

We can do without, yes. Seems more simple that way.

> It's all scratch space for the RM.
> Does the release branch get moved to a tag at the end?

Yes, that line was missing, I saw too late and did not
want to add another mail to my wall of text. So

> svn mv branches/2.4.49-candidate tags/2.4.49

would be the last thing at the voting.

Re: release scripts

[Eric Covener]

On Wed, Sep 1, 2021 at 6:08 AM ste...@eissing.org  wrote:
>
> Having a look at the release scripts and how they work.
>
> I think we can use SVN and its branches/tags in a bit smarter way
> and make things easier. As Christophe mentioned, he would like a
> "--dry-run" option, because when things do not run smoothly to the
> end, you have not only a local messed-up state but the SVN repro
> itself is also changed without easy remedies.

LGTM. Maybe even separate -tmp and -candidate branches aren't needed?
It's all scratch space for the RM.
Does the release branch get moved to a tag at the end?

Re: release scripts

[Eric Covener]

>check PGP/GPG key in httpd-dist/KEYS

This reminds me, when I looked the other day you did not yet have an
entry in KEYS (svn co https://dist.apache.org/repos/dist/release/httpd
httpd-dist)

Re: release scripts

[Ruediger Pluem]

On 9/1/21 12:08 PM, ste...@eissing.org wrote:
> Having a look at the release scripts and how they work. 
> 
> I think we can use SVN and its branches/tags in a bit smarter way
> and make things easier. As Christophe mentioned, he would like a
> "--dry-run" option, because when things do not run smoothly to the
> end, you have not only a local messed-up state but the SVN repro
> itself is also changed without easy remedies.
> 
> I propose to do all work up to release testing in separate,
> temporary branches that can simply be removed and restarted.
> This would not require a rewrite of the release scripts, but
> some re-ordering and branch name changes.
> 
> - checkout branches/2.4.x
>   - make sure change-entries are merged, commit
>   - test branch locally for health
>   - svn cp . branches/2.4.49-tmp
> - svn switch to branches/2.4.49-tmp
>   - update versions, build docs, etc on that
>   - commit this into branches/2.4.49-tmp
>   - svn mv branches/2.4.49-tmp branches/2.4.49-candidate
> - svn switch to branches/2.4.49-candidate
>   - create tar files and signature from -candidate
>   - make them available for testing
>   - announce release voting
> #
> # everything up to here can be reverted by "svn rm"
> #
> - switch to branches/2.4.x 
>   - bump versions in branches/2.4.x to 2.4.50

Sounds good. One addition on this flow: I would like to see the build docs 
results finding their way back into the 2.4.x branch.
Probably by redoing build docs after switching back to branches 2.4 in the last 
step.

Regards

Rüdiger

Re: release?

[Dave Fisher]

> On Aug 31, 2021, at 4:12 AM, Daniel Ruggeri  wrote:
> 
> 
> On 8/30/2021 3:53 PM, Christophe JAILLET wrote:
>> 
>> Le 30/08/2021 à 13:53, Eric Covener a écrit : 
>>> On Mon, Aug 30, 2021 at 7:36 AM ste...@eissing.org 
>>>   
>>>  wrote: 
 In what state is our release handling? Given someone holding my hand, 
 could I do it? Or is it better to look someone over the shoulder while he 
 does it? 
>>> If there is an over-the-shoulder session I would like to tag along.  I 
>>> am flexible on time of day but I am GMT+4 (EDT).  I can host on webex. 
>>> Otherwise if you just want to struggle through it I can tag along but 
>>> I have no experience. 
>> 
>> I can give another try with my limited experience. 
>> 
>> I definitively would like to add a --dry-run option for all scripts so that 
>> they can be run for learning purpose without the fear of un-expected impact 
>> on svn. 
> FWIW, the announce.sh script which collates all the security "stuff" and 
> sends the announce emails drops the user to a shell to inspect/examine what 
> WILL happen before actually doing anything. Any non-zero return code of that 
> shell will abort the process. I used the heck out of that several times :-)
> 
> 
> 
>> 
>> Existing scripts are not that easy to read at first, but are understanbdable 
>> and followinghttp://httpd.apache.org/dev/release.html#how-to-do-a-release 
>>  helps a lot. 
>> The scripts should also be tweaked because of the latest changes in several 
>> places (at least web site update (now on github) and CVE announcement (if 
>> any) now that part of the process is handled elsewhere). 
>> 
> 
> +1
> 
> To my knowledge, the publishing of the site and overhaul of the new CVE 
> process are the things requiring updates.
> 

The JSON files for the release’s CVEs should be committed here: 
https://github.com/apache/httpd-site/tree/main/content/security/json 
 : 
https://gitbox.apache.org/repos/asf?p=httpd-site.git;a=tree;f=content/security/json;hb=HEAD
 



> -- 
> Daniel Ruggeri
>> The CVE announcement should be much easier, now that we have a "Send these 
>> Emails" on cveprocess.a.o. This should simplify part of the process where we 
>> were preparing some scripts to send the announcement emails. 
>> 
>> I've been lacking time for httpd since many weeks, but I should be able to 
>> RM next week if needed. 
>> 
>> CJ 
>> 
>>> Also: Anyone who has a showstopper to delay a release (even if not yet 
>>> proposed) please add it to 2.4.x STATUS so we can get things in order. 
>>> 

Re: release?

[Ruediger Pluem]

On 8/31/21 8:57 PM, Christophe JAILLET wrote:
> 
> Le 31/08/2021 à 20:25, Eric Covener a écrit :
>>
>> Should we think about reverting the recent mod_unique_id changes?  It
>> seems like that was noticed pretty quickly but I think the current
>> problem is still not well understood. Meanwhile the original problem
>> on the old codebase wasn't widely reported.
> 
> +1
> 
> We can also easily narrow the time window where duplicate can be generated by 
> just reordering the previous code.

Yes, looks like the old code base was "better". So let's do the improvement you 
mention and take some time for
reviewing the rewrite proposals that have been made on the Github PR.

Regards

Rüdiger

Re: release?

[Christophe JAILLET]

Le 31/08/2021 à 20:25, Eric Covener a écrit :


Should we think about reverting the recent mod_unique_id changes?  It
seems like that was noticed pretty quickly but I think the current
problem is still not well understood. Meanwhile the original problem
on the old codebase wasn't widely reported.


+1

We can also easily narrow the time window where duplicate can be 
generated by just reordering the previous code.


CJ

Re: release?

[Eric Covener]

On Mon, Aug 30, 2021 at 12:41 PM Yann Ylavic  wrote:
>
> On Mon, Aug 30, 2021 at 1:54 PM Eric Covener  wrote:
> >
> > Also: Anyone who has a showstopper to delay a release (even if not yet
> > proposed) please add it to 2.4.x STATUS so we can get things in order.
>
> I think that BZ 65519 and 65521 are showstoppers, I'm waiting for
> feedbacks from the OP to commit to trunk and propose the backport, but
> if it lasts too long I'll do it anyway..

+1, that POLLHUP one was one I was thinking of.

Should we think about reverting the recent mod_unique_id changes?  It
seems like that was noticed pretty quickly but I think the current
problem is still not well understood. Meanwhile the original problem
on the old codebase wasn't widely reported.

Re: release?

[ste...@eissing.org]

> Am 30.08.2021 um 22:53 schrieb Christophe JAILLET 
> :
> 
> 
> Le 30/08/2021 à 13:53, Eric Covener a écrit :
>> On Mon, Aug 30, 2021 at 7:36 AM ste...@eissing.org  
>> wrote:
>>> In what state is our release handling? Given someone holding my hand, could 
>>> I do it? Or is it better to look someone over the shoulder while he does it?
>> If there is an over-the-shoulder session I would like to tag along.  I
>> am flexible on time of day but I am GMT+4 (EDT).  I can host on webex.
>> Otherwise if you just want to struggle through it I can tag along but
>> I have no experience.
> 
> I can give another try with my limited experience.
> 
> I definitively would like to add a --dry-run option for all scripts so that 
> they can be run for learning purpose without the fear of un-expected impact 
> on svn.
> 
> Existing scripts are not that easy to read at first, but are understanbdable 
> and following http://httpd.apache.org/dev/release.html#how-to-do-a-release 
> helps a lot. The scripts should also be tweaked because of the latest changes 
> in several places (at least web site update (now on github) and CVE 
> announcement (if any) now that part of the process is handled elsewhere).
> 
> The CVE announcement should be much easier, now that we have a "Send these 
> Emails" on cveprocess.a.o. This should simplify part of the process where we 
> were preparing some scripts to send the announcement emails.
> 
> I've been lacking time for httpd since many weeks, but I should be able to RM 
> next week if needed.

I would like to look over your shoulder/help where I can. Maybe Eric can make a 
WebEx for us - that would make following along much easier, I guess.

Looking at the description link (thanks) I see that there are still a lot of 
"manual" things involved. And a "--dry-run" is definitely a thing we want. Will 
have a look at those scripts in the next days, to see what I can add here.

- Stefan
> 
> CJ
> 
>> Also: Anyone who has a showstopper to delay a release (even if not yet
>> proposed) please add it to 2.4.x STATUS so we can get things in order.
>> 

Re: release?

[Daniel Ruggeri]

On 8/30/2021 3:53 PM, Christophe JAILLET wrote:
>
> Le 30/08/2021 à 13:53, Eric Covener a écrit :
>> On Mon, Aug 30, 2021 at 7:36 AM ste...@eissing.org
>>  wrote:
>>> In what state is our release handling? Given someone holding my
>>> hand, could I do it? Or is it better to look someone over the
>>> shoulder while he does it?
>> If there is an over-the-shoulder session I would like to tag along.  I
>> am flexible on time of day but I am GMT+4 (EDT).  I can host on webex.
>> Otherwise if you just want to struggle through it I can tag along but
>> I have no experience.
>
> I can give another try with my limited experience.
>
> I definitively would like to add a --dry-run option for all scripts so
> that they can be run for learning purpose without the fear of
> un-expected impact on svn.

FWIW, the announce.sh script which collates all the security "stuff" and
sends the announce emails drops the user to a shell to inspect/examine
what WILL happen before actually doing anything. Any non-zero return
code of that shell will abort the process. I used the heck out of that
several times :-)


>
> Existing scripts are not that easy to read at first, but are
> understanbdable and following
> http://httpd.apache.org/dev/release.html#how-to-do-a-release helps a
> lot. The scripts should also be tweaked because of the latest changes
> in several places (at least web site update (now on github) and CVE
> announcement (if any) now that part of the process is handled elsewhere).
>

+1

To my knowledge, the publishing of the site and overhaul of the new CVE
process are the things requiring updates.

-- 
Daniel Ruggeri

> The CVE announcement should be much easier, now that we have a "Send
> these Emails" on cveprocess.a.o. This should simplify part of the
> process where we were preparing some scripts to send the announcement
> emails.
>
> I've been lacking time for httpd since many weeks, but I should be
> able to RM next week if needed.
>
> CJ
>
>> Also: Anyone who has a showstopper to delay a release (even if not yet
>> proposed) please add it to 2.4.x STATUS so we can get things in order.
>>

Re: release?

[Graham Leggett]

On 30 Aug 2021, at 12:35, ste...@eissing.org wrote:

> In what state is our release handling? Given someone holding my hand, could 
> I do it? Or is it better to look someone over the shoulder while he does it?

When I did it in the past, I walked through the commit emails of previous 
releases, and performed the same steps.

Regards,
Graham
—

Re: release?

[Christophe JAILLET]

Le 30/08/2021 à 13:53, Eric Covener a écrit :

On Mon, Aug 30, 2021 at 7:36 AM ste...@eissing.org  wrote:

In what state is our release handling? Given someone holding my hand, could I 
do it? Or is it better to look someone over the shoulder while he does it?

If there is an over-the-shoulder session I would like to tag along.  I
am flexible on time of day but I am GMT+4 (EDT).  I can host on webex.
Otherwise if you just want to struggle through it I can tag along but
I have no experience.


I can give another try with my limited experience.

I definitively would like to add a --dry-run option for all scripts so 
that they can be run for learning purpose without the fear of 
un-expected impact on svn.


Existing scripts are not that easy to read at first, but are 
understanbdable and following 
http://httpd.apache.org/dev/release.html#how-to-do-a-release helps a 
lot. The scripts should also be tweaked because of the latest changes in 
several places (at least web site update (now on github) and CVE 
announcement (if any) now that part of the process is handled elsewhere).


The CVE announcement should be much easier, now that we have a "Send 
these Emails" on cveprocess.a.o. This should simplify part of the 
process where we were preparing some scripts to send the announcement 
emails.


I've been lacking time for httpd since many weeks, but I should be able 
to RM next week if needed.


CJ


Also: Anyone who has a showstopper to delay a release (even if not yet
proposed) please add it to 2.4.x STATUS so we can get things in order.

Re: release?

[Yann Ylavic]

On Mon, Aug 30, 2021 at 1:54 PM Eric Covener  wrote:
>
> Also: Anyone who has a showstopper to delay a release (even if not yet
> proposed) please add it to 2.4.x STATUS so we can get things in order.

I think that BZ 65519 and 65521 are showstoppers, I'm waiting for
feedbacks from the OP to commit to trunk and propose the backport, but
if it lasts too long I'll do it anyway..


Cheers;
Yann.

Re: release?

[Eric Covener]

On Mon, Aug 30, 2021 at 7:36 AM ste...@eissing.org  wrote:
>
> In what state is our release handling? Given someone holding my hand, could I 
> do it? Or is it better to look someone over the shoulder while he does it?

If there is an over-the-shoulder session I would like to tag along.  I
am flexible on time of day but I am GMT+4 (EDT).  I can host on webex.
Otherwise if you just want to struggle through it I can tag along but
I have no experience.

Also: Anyone who has a showstopper to delay a release (even if not yet
proposed) please add it to 2.4.x STATUS so we can get things in order.

-- 
Eric Covener
cove...@gmail.com

Re: [RELEASE CANDIDATE] Apache-Test-1.42 RC1

[Steve Hay]

On Mon, 19 Aug 2019 at 14:10, Steve Hay  wrote:
>
> Please download, test, and report back on this Apache-Test 1.42
> release candidate.
>
> https://dist.apache.org/repos/dist/dev/perl/Apache-Test-1.42-rc1.tar.gz
>
> MD5  = 2dd753a50d94ee1705f77039d5da2f3a
> SHA1 = c07e19bb63fe5ef845a91fefea58a7c28bfedf34
>
> The only change in this release is:
>
> Fix loading apache_test_config.pm for recent perls in which '.' is
> no longer in @INC by default. [Steve Hay]

+1 from me using VC++ 2019 64-bit, Perl 5.30.0, Apache 2.4.39, with
and without the current Trunk version of mod_perl (soon to be 2.0.11
RC1 once I get this updated Apache-Test in).

Re: release?

[Eric Covener]

> Is this release likely to be ready before August 10? I am guessing "no" at 
> this point, but wanted to get an idea early.

Not likely

RE: release?

[Mark Blackman]

Hi,

Is this release likely to be ready before August 10? I am guessing "no" at this 
point, but wanted to get an idea early.

Cheers,
Mark

-Original Message-
From: Rainer Jung [mailto:rainer.j...@kippdata.de]
Sent: 20 July 2019 10:44
To: dev@httpd.apache.org
Subject: Re: release?

m 20.07.2019 um 10:38 schrieb Marion & Christophe JAILLET:
> Hi,
>
> PR60757 and corresponding r1853560 could be a good candidate for backport.
>
> I don't have a configuration for testing so I won't propose it myself
> for backport, but the patch looks simple.

I have added this one (mod_proxy_hcheck in BalancerMember) and two other ones 
("Mute frequent debug message in mod_proxy_hcheck" and "bytraffic needs 
byrequests") to STATUS right now.

Regards,

Rainer

> Le 18/07/2019 à 16:06, Stefan Eissing a écrit :
>> It would be great if we could make a release this month. There are
>> several fixes and improvements already backported and a few
>> outstanding issues that need a vote or two.
>>
>> Please have a look if you find the time. I think Daniel expressed
>> willingness to RM this? That'd be great!
>>
>> Cheers, Stefan


---
This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and delete this e-mail. Any unauthorized copying, 
disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to https://www.db.com/disclosures for additional EU corporate and 
regulatory disclosures and to 
http://www.db.com/unitedkingdom/content/privacy.htm for information about 
privacy.

Re: release?

[Rainer Jung]

m 20.07.2019 um 10:38 schrieb Marion & Christophe JAILLET:

Hi,

PR60757 and corresponding r1853560 could be a good candidate for backport.

I don't have a configuration for testing so I won't propose it myself 
for backport, but the patch looks simple.


I have added this one (mod_proxy_hcheck in BalancerMember) and two other 
ones ("Mute frequent debug message in mod_proxy_hcheck" and "bytraffic 
needs byrequests") to STATUS right now.


Regards,

Rainer


Le 18/07/2019 à 16:06, Stefan Eissing a écrit :
It would be great if we could make a release this month. There are 
several fixes and improvements already backported and a few 
outstanding issues that need a vote or two.


Please have a look if you find the time. I think Daniel expressed 
willingness to RM this? That'd be great!


Cheers, Stefan

Re: release?

[Marion & Christophe JAILLET]

Hi,

PR60757 and corresponding r1853560 could be a good candidate for backport.

I don't have a configuration for testing so I won't propose it myself 
for backport, but the patch looks simple.


CJ

Le 18/07/2019 à 16:06, Stefan Eissing a écrit :

It would be great if we could make a release this month. There are several 
fixes and improvements already backported and a few outstanding issues that 
need a vote or two.

Please have a look if you find the time. I think Daniel expressed willingness 
to RM this? That'd be great!

Cheers, Stefan

Re: release?

[Jim Jagielski]

> On Jul 19, 2019, at 7:41 AM, Daniel Ruggeri  wrote:
> 
> Argh. I guess my mail client ate my response.
> 
> I replied yesterday with a +1 and offered to begin the process Friday (a week 
> from today).
> 
> I am available for being RM since the heavy lifting is scripted, but if you 
> would prefer to, it's all yours, Jim :-)
> 

I wouldn't mind giving it a spin... might be a good way to get a wider UX on 
the scripting.

> Happy weekend!
> -- 
> Daniel Ruggeri
> 
> On July 19, 2019 6:34:10 AM CDT, Jim Jagielski  wrote:
> +1. If Daniel doesn't have the time, I can.
> 
> On Jul 18, 2019, at 10:06 AM, Stefan Eissing  
> wrote:
> 
> It would be great if we could make a release this month. There are several 
> fixes and improvements already backported and a few outstanding issues that 
> need a vote or two. 
> 
> Please have a look if you find the time. I think Daniel expressed willingness 
> to RM this? That'd be great!
> 
> Cheers, Stefan
> 

Re: release?

[Jim Jagielski]

+1. If Daniel doesn't have the time, I can.

> On Jul 18, 2019, at 10:06 AM, Stefan Eissing  
> wrote:
> 
> It would be great if we could make a release this month. There are several 
> fixes and improvements already backported and a few outstanding issues that 
> need a vote or two. 
> 
> Please have a look if you find the time. I think Daniel expressed willingness 
> to RM this? That'd be great!
> 
> Cheers, Stefan

Re: [RELEASE CANDIDATE] Apache-Test-1.41 RC1

[Steve Hay]

On Wed, 10 Jul 2019 at 22:07, Philippe M. Chiasson  wrote:
>
> Tested on Fedora 30 with Apache/2.4.39, looking good to me
>
> That's my +1
>

Thanks to all for testing. With the +1 from Adam Prime (sent
privately) that's enough :-)

Re: [RELEASE CANDIDATE] Apache-Test-1.41 RC1

[Philippe M. Chiasson]

Tested on Fedora 30 with Apache/2.4.39, looking good to me

That's my +1

On 2019-07-03 3:45 a.m., Steve Hay wrote:
> Please download, test, and report back on this Apache-Test 1.41
> release candidate.
>
> https://dist.apache.org/repos/dist/dev/perl/Apache-Test-1.41-rc1.tar.gz
>
> MD5  = 7933d3a6a762f087bf7883a1ac2086eb
> SHA1 = 17aa9a8669023aa2f485aa83f8f389969b8e5f0c
>
> Major changes in this release are as follows:
>
> Set DefaultStateDir for > 2.5.1 and add -t_state to override. [jorton]
>
> Inherit config via IncludeOptional as well as Include. [jorton]
>
> Increase size of MinSpare, MaxSpare and MaxClients to improve httpd
> test framework runs with worker and preform MPMs. [rjung]
>
> Changed the openssl version detection to work with other *SSL libraries. 
> [icing]
>
> Switch test framework from using Net::SSL for raw TLS sockets to
> IO::Socket::SSL. [rjung]
>
> Fix mod_ssl tests under OpenSSL 1.1.1 / TLSv1.3. [jorton]
>
> Add cwd to generated lib path in TEST script since Perl >=5.26 don't
> do that any more. [jorton]
>
> Override loglevel to trace8 if running in 2.4. [covener]
>
> Allow an empty PREFIX. [sf]
>
> Add need_min_apache_fix(). [covener]
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
> For additional commands, e-mail: dev-h...@perl.apache.org
>



signature.asc
Description: OpenPGP digital signature

Re: [RELEASE CANDIDATE] Apache-Test-1.41 RC1

[Joe Orton]

On Wed, Jul 03, 2019 at 08:45:36AM +0100, Steve Hay wrote:
> Please download, test, and report back on this Apache-Test 1.41
> release candidate.
> 
> https://dist.apache.org/repos/dist/dev/perl/Apache-Test-1.41-rc1.tar.gz
> 
> MD5  = 7933d3a6a762f087bf7883a1ac2086eb
> SHA1 = 17aa9a8669023aa2f485aa83f8f389969b8e5f0c

I can't remember if I'm a PMC member for perl.a.o but +1 for release 
from me, this looks good to me.

Regards, Joe

Re: [RELEASE CANDIDATE] Apache-Test-1.41 RC1

[Steve Hay]

On Wed, 3 Jul 2019 at 08:45, Steve Hay  wrote:
>
> Please download, test, and report back on this Apache-Test 1.41
> release candidate.
>
> https://dist.apache.org/repos/dist/dev/perl/Apache-Test-1.41-rc1.tar.gz
>

+1 from me using the following setups:

VC++ 2013 32-bit, Perl 5.30.0, Apache 2.2.34
VC++ 2019 64-bit, Perl 5.30.0, Apache 2.4.39

Both setups tested in four configurations: With & without mod_perl
2.0.10 / with & without LWP.

Re: [RELEASE CANDIDATE] Apache-Test-1.41 RC1

[Philippe Chiasson]

Fantastic! Thanks Steve! Will be giving this a spin today 

Sent from the depths of my mind on an iPhone

> On Jul 3, 2019, at 03:45, Steve Hay  wrote:
> 
> Please download, test, and report back on this Apache-Test 1.41
> release candidate.
> 
> https://dist.apache.org/repos/dist/dev/perl/Apache-Test-1.41-rc1.tar.gz
> 
> MD5  = 7933d3a6a762f087bf7883a1ac2086eb
> SHA1 = 17aa9a8669023aa2f485aa83f8f389969b8e5f0c
> 
> Major changes in this release are as follows:
> 
> Set DefaultStateDir for > 2.5.1 and add -t_state to override. [jorton]
> 
> Inherit config via IncludeOptional as well as Include. [jorton]
> 
> Increase size of MinSpare, MaxSpare and MaxClients to improve httpd
> test framework runs with worker and preform MPMs. [rjung]
> 
> Changed the openssl version detection to work with other *SSL libraries. 
> [icing]
> 
> Switch test framework from using Net::SSL for raw TLS sockets to
> IO::Socket::SSL. [rjung]
> 
> Fix mod_ssl tests under OpenSSL 1.1.1 / TLSv1.3. [jorton]
> 
> Add cwd to generated lib path in TEST script since Perl >=5.26 don't
> do that any more. [jorton]
> 
> Override loglevel to trace8 if running in 2.4. [covener]
> 
> Allow an empty PREFIX. [sf]
> 
> Add need_min_apache_fix(). [covener]
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
> For additional commands, e-mail: dev-h...@perl.apache.org
> 

Re: release v1.9.2

[Stefan Priebe - Profihost AG]

Am 09.03.2017 um 18:09 schrieb Stefan Eissing:
> Thanks for running our patches with many changes! Not a mistake to have it 
> running fine for four days. ;-)
> 
> Hmm, so we hunt a rare beast. After much effort from all sides we made it 
> rare. So, nothing to be ashamed of. Need to keep looking...

May be Yann has an idea? May be it's not related to http2 at all?

Stefan

>> Am 09.03.2017 um 17:32 schrieb Stefan Priebe - Profihost AG 
>> :
>>
>> Hi Stefan,
>>
>> while doing longer testing i can say that also the version which was
>> working for 4 days segfaults. So it was never solved ;-( Sorry about
>> that. Testing was just too short.
>>
>> Greets,
>> Stefan
>>
>> Am 05.03.2017 um 14:49 schrieb Stefan Priebe - Profihost AG:
>>> Hi Stefan,
>>>
>>> yes this seems to correct BUT i'm not sure i the test was long enough
>>> where i hadn't a segfault. I'll rerun a test with that version. To
>>> verify this was no just a "fault".
>>>
>>> Greets,
>>> Stefan
>>> Am 05.03.2017 um 14:34 schrieb Stefan Eissing:
 Thanks. I try to summarize:

 - we did see this rarely with unpatched v1.9.2 and Yann's mpm patch v??
 - we still see this rarely with the patch adding mutex to the main conn 
 allocator (so this seems not to change anything)
 - we did not see this with v1.9.2 and Yann's patch on ptrans version  ??

 Is this correct?

> Am 04.03.2017 um 22:34 schrieb Stefan Priebe - Profihost AG 
> :
>
> Hi Stefan,
>
> current trace - not sure whether this is http2 related at all:
>
> Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  allocator_free (node=0x0, allocator=0x7fbf4c05a410)
>   at memory/unix/apr_pools.c:381
> #0  allocator_free (node=0x0, allocator=0x7fbf4c05a410)
>   at memory/unix/apr_pools.c:381
> #1  apr_pool_clear (pool=0x7fbf4c04f888) at memory/unix/apr_pools.c:793
> #2  0x5642878c2818 in ap_push_pool (queue_info=0x0,
>   pool_to_recycle=0x7fbf4c05a418) at fdqueue.c:234
> #3  0x5642878bdb5a in process_lingering_close (cs=0x7fbf4c04fb18,
>   pfd=0x5642886c7078) at event.c:1513
> #4  0x5642878c1690 in listener_thread (thd=0x0, dummy=0x549eb52311a6f)
>   at event.c:1837
> #5  0x7fbf5f2940a4 in start_thread ()
>  from /lib/x86_64-linux-gnu/libpthread.so.0
> #6  0x7fbf5efc962d in clone () from /lib/x86_64-linux-gnu/libc.so.6
>
> Stefan
>
>> Am 03.03.2017 um 21:02 schrieb Stefan Priebe - Profihost AG:
>> Hi Stefan,
>>
>> live. Sorry for the late reply.
>>
>> Stefan
>>
>>> Am 28.02.2017 um 11:49 schrieb Stefan Eissing:
>>> Meh, my mistake. Sorry about that. Did not cleanup properly. Dare you 
>>> with an improved version:
>>>
>>>
>>>
>>>
>>>
 Am 28.02.2017 um 08:41 schrieb Stefan Priebe - Profihost AG 
 :

 That one breaks everyting. Multiple crashes per second.

 [Thread debugging using libthread_db enabled]
 Using host libthread_db library 
 "/lib/x86_64-linux-gnu/libthread_db.so.1".
 Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
 Program terminated with signal SIGABRT, Aborted.
 #0  0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
 #0  0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
 #1  0x7f02724eb448 in abort () from /lib/x86_64-linux-gnu/libc.so.6
 #2  0x7f02724e3266 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
 #3  0x7f02724e3312 in __assert_fail () from
 /lib/x86_64-linux-gnu/libc.so.6
 #4  0x7f027287062f in __pthread_tpp_change_priority ()
 from /lib/x86_64-linux-gnu/libpthread.so.0
 #5  0x7f0272865e9f in __pthread_mutex_lock_full ()
 from /lib/x86_64-linux-gnu/libpthread.so.0
 #6  0x7f0272a98db8 in allocator_alloc (in_size=in_size@entry=8032,
  allocator=0x7f025c03f3c0) at memory/unix/apr_pools.c:244
 #7  apr_allocator_alloc (allocator=0x7f025c03f3c0, 
 size=size@entry=8032)
  at memory/unix/apr_pools.c:438
 #8  0x7f0272cbcac4 in apr_bucket_alloc (size=8032, size@entry=8000,
  list=0x7f022c0008e8) at buckets/apr_buckets_alloc.c:157
 #9  0x7f0272cbdca2 in socket_bucket_read (a=0x7f022c000b08,
  str=0x7f02627a87b8, len=0x7f02627a87c0, block=)
  at buckets/apr_buckets_socket.c:34
 #10 0x565098cf1fb1 in ap_core_input_filter (f=0x7f022c0056b0,
  b=0x7f022c005630, mode=, block=APR_NONBLOCK_READ,
  readbytes=5) at core_filters.c:235
 #11 0x565098d3aaca in logio_in_filter (f=,
  bb=0x7f022c005630, mode=, block=,
  readbytes=) at mod_logio.c:165
 #12 

Re: release v1.9.2

[Stefan Eissing]

Thanks for running our patches with many changes! Not a mistake to have it 
running fine for four days. ;-)

Hmm, so we hunt a rare beast. After much effort from all sides we made it rare. 
So, nothing to be ashamed of. Need to keep looking...

> Am 09.03.2017 um 17:32 schrieb Stefan Priebe - Profihost AG 
> :
> 
> Hi Stefan,
> 
> while doing longer testing i can say that also the version which was
> working for 4 days segfaults. So it was never solved ;-( Sorry about
> that. Testing was just too short.
> 
> Greets,
> Stefan
> 
> Am 05.03.2017 um 14:49 schrieb Stefan Priebe - Profihost AG:
>> Hi Stefan,
>> 
>> yes this seems to correct BUT i'm not sure i the test was long enough
>> where i hadn't a segfault. I'll rerun a test with that version. To
>> verify this was no just a "fault".
>> 
>> Greets,
>> Stefan
>> Am 05.03.2017 um 14:34 schrieb Stefan Eissing:
>>> Thanks. I try to summarize:
>>> 
>>> - we did see this rarely with unpatched v1.9.2 and Yann's mpm patch v??
>>> - we still see this rarely with the patch adding mutex to the main conn 
>>> allocator (so this seems not to change anything)
>>> - we did not see this with v1.9.2 and Yann's patch on ptrans version  ??
>>> 
>>> Is this correct?
>>> 
 Am 04.03.2017 um 22:34 schrieb Stefan Priebe - Profihost AG 
 :
 
 Hi Stefan,
 
 current trace - not sure whether this is http2 related at all:
 
 Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
 Program terminated with signal SIGSEGV, Segmentation fault.
 #0  allocator_free (node=0x0, allocator=0x7fbf4c05a410)
   at memory/unix/apr_pools.c:381
 #0  allocator_free (node=0x0, allocator=0x7fbf4c05a410)
   at memory/unix/apr_pools.c:381
 #1  apr_pool_clear (pool=0x7fbf4c04f888) at memory/unix/apr_pools.c:793
 #2  0x5642878c2818 in ap_push_pool (queue_info=0x0,
   pool_to_recycle=0x7fbf4c05a418) at fdqueue.c:234
 #3  0x5642878bdb5a in process_lingering_close (cs=0x7fbf4c04fb18,
   pfd=0x5642886c7078) at event.c:1513
 #4  0x5642878c1690 in listener_thread (thd=0x0, dummy=0x549eb52311a6f)
   at event.c:1837
 #5  0x7fbf5f2940a4 in start_thread ()
  from /lib/x86_64-linux-gnu/libpthread.so.0
 #6  0x7fbf5efc962d in clone () from /lib/x86_64-linux-gnu/libc.so.6
 
 Stefan
 
> Am 03.03.2017 um 21:02 schrieb Stefan Priebe - Profihost AG:
> Hi Stefan,
> 
> live. Sorry for the late reply.
> 
> Stefan
> 
>> Am 28.02.2017 um 11:49 schrieb Stefan Eissing:
>> Meh, my mistake. Sorry about that. Did not cleanup properly. Dare you 
>> with an improved version:
>> 
>> 
>> 
>> 
>> 
>>> Am 28.02.2017 um 08:41 schrieb Stefan Priebe - Profihost AG 
>>> :
>>> 
>>> That one breaks everyting. Multiple crashes per second.
>>> 
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library 
>>> "/lib/x86_64-linux-gnu/libthread_db.so.1".
>>> Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
>>> Program terminated with signal SIGABRT, Aborted.
>>> #0  0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
>>> #0  0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
>>> #1  0x7f02724eb448 in abort () from /lib/x86_64-linux-gnu/libc.so.6
>>> #2  0x7f02724e3266 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>>> #3  0x7f02724e3312 in __assert_fail () from
>>> /lib/x86_64-linux-gnu/libc.so.6
>>> #4  0x7f027287062f in __pthread_tpp_change_priority ()
>>> from /lib/x86_64-linux-gnu/libpthread.so.0
>>> #5  0x7f0272865e9f in __pthread_mutex_lock_full ()
>>> from /lib/x86_64-linux-gnu/libpthread.so.0
>>> #6  0x7f0272a98db8 in allocator_alloc (in_size=in_size@entry=8032,
>>>  allocator=0x7f025c03f3c0) at memory/unix/apr_pools.c:244
>>> #7  apr_allocator_alloc (allocator=0x7f025c03f3c0, size=size@entry=8032)
>>>  at memory/unix/apr_pools.c:438
>>> #8  0x7f0272cbcac4 in apr_bucket_alloc (size=8032, size@entry=8000,
>>>  list=0x7f022c0008e8) at buckets/apr_buckets_alloc.c:157
>>> #9  0x7f0272cbdca2 in socket_bucket_read (a=0x7f022c000b08,
>>>  str=0x7f02627a87b8, len=0x7f02627a87c0, block=)
>>>  at buckets/apr_buckets_socket.c:34
>>> #10 0x565098cf1fb1 in ap_core_input_filter (f=0x7f022c0056b0,
>>>  b=0x7f022c005630, mode=, block=APR_NONBLOCK_READ,
>>>  readbytes=5) at core_filters.c:235
>>> #11 0x565098d3aaca in logio_in_filter (f=,
>>>  bb=0x7f022c005630, mode=, block=,
>>>  readbytes=) at mod_logio.c:165
>>> #12 0x565098d45b9a in bio_filter_in_read (bio=0x7f024800b460,
>>>  in=0x7f02480492a3 "", inlen=5) at ssl_engine_io.c:483
>>> #13 0x7f02736b014c in BIO_read ()
>>> from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0

Re: release v1.9.2

[Stefan Priebe - Profihost AG]

Hi Stefan,

while doing longer testing i can say that also the version which was
working for 4 days segfaults. So it was never solved ;-( Sorry about
that. Testing was just too short.

Greets,
Stefan

Am 05.03.2017 um 14:49 schrieb Stefan Priebe - Profihost AG:
> Hi Stefan,
> 
> yes this seems to correct BUT i'm not sure i the test was long enough
> where i hadn't a segfault. I'll rerun a test with that version. To
> verify this was no just a "fault".
> 
> Greets,
> Stefan
> Am 05.03.2017 um 14:34 schrieb Stefan Eissing:
>> Thanks. I try to summarize:
>>
>> - we did see this rarely with unpatched v1.9.2 and Yann's mpm patch v??
>> - we still see this rarely with the patch adding mutex to the main conn 
>> allocator (so this seems not to change anything)
>> - we did not see this with v1.9.2 and Yann's patch on ptrans version  ??
>>
>> Is this correct?
>>
>>> Am 04.03.2017 um 22:34 schrieb Stefan Priebe - Profihost AG 
>>> :
>>>
>>> Hi Stefan,
>>>
>>> current trace - not sure whether this is http2 related at all:
>>>
>>> Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
>>> Program terminated with signal SIGSEGV, Segmentation fault.
>>> #0  allocator_free (node=0x0, allocator=0x7fbf4c05a410)
>>>at memory/unix/apr_pools.c:381
>>> #0  allocator_free (node=0x0, allocator=0x7fbf4c05a410)
>>>at memory/unix/apr_pools.c:381
>>> #1  apr_pool_clear (pool=0x7fbf4c04f888) at memory/unix/apr_pools.c:793
>>> #2  0x5642878c2818 in ap_push_pool (queue_info=0x0,
>>>pool_to_recycle=0x7fbf4c05a418) at fdqueue.c:234
>>> #3  0x5642878bdb5a in process_lingering_close (cs=0x7fbf4c04fb18,
>>>pfd=0x5642886c7078) at event.c:1513
>>> #4  0x5642878c1690 in listener_thread (thd=0x0, dummy=0x549eb52311a6f)
>>>at event.c:1837
>>> #5  0x7fbf5f2940a4 in start_thread ()
>>>   from /lib/x86_64-linux-gnu/libpthread.so.0
>>> #6  0x7fbf5efc962d in clone () from /lib/x86_64-linux-gnu/libc.so.6
>>>
>>> Stefan
>>>
 Am 03.03.2017 um 21:02 schrieb Stefan Priebe - Profihost AG:
 Hi Stefan,

 live. Sorry for the late reply.

 Stefan

> Am 28.02.2017 um 11:49 schrieb Stefan Eissing:
> Meh, my mistake. Sorry about that. Did not cleanup properly. Dare you 
> with an improved version:
>
>
>
>
>
>> Am 28.02.2017 um 08:41 schrieb Stefan Priebe - Profihost AG 
>> :
>>
>> That one breaks everyting. Multiple crashes per second.
>>
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library 
>> "/lib/x86_64-linux-gnu/libthread_db.so.1".
>> Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
>> Program terminated with signal SIGABRT, Aborted.
>> #0  0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
>> #0  0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
>> #1  0x7f02724eb448 in abort () from /lib/x86_64-linux-gnu/libc.so.6
>> #2  0x7f02724e3266 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>> #3  0x7f02724e3312 in __assert_fail () from
>> /lib/x86_64-linux-gnu/libc.so.6
>> #4  0x7f027287062f in __pthread_tpp_change_priority ()
>>  from /lib/x86_64-linux-gnu/libpthread.so.0
>> #5  0x7f0272865e9f in __pthread_mutex_lock_full ()
>>  from /lib/x86_64-linux-gnu/libpthread.so.0
>> #6  0x7f0272a98db8 in allocator_alloc (in_size=in_size@entry=8032,
>>   allocator=0x7f025c03f3c0) at memory/unix/apr_pools.c:244
>> #7  apr_allocator_alloc (allocator=0x7f025c03f3c0, size=size@entry=8032)
>>   at memory/unix/apr_pools.c:438
>> #8  0x7f0272cbcac4 in apr_bucket_alloc (size=8032, size@entry=8000,
>>   list=0x7f022c0008e8) at buckets/apr_buckets_alloc.c:157
>> #9  0x7f0272cbdca2 in socket_bucket_read (a=0x7f022c000b08,
>>   str=0x7f02627a87b8, len=0x7f02627a87c0, block=)
>>   at buckets/apr_buckets_socket.c:34
>> #10 0x565098cf1fb1 in ap_core_input_filter (f=0x7f022c0056b0,
>>   b=0x7f022c005630, mode=, block=APR_NONBLOCK_READ,
>>   readbytes=5) at core_filters.c:235
>> #11 0x565098d3aaca in logio_in_filter (f=,
>>   bb=0x7f022c005630, mode=, block=,
>>   readbytes=) at mod_logio.c:165
>> #12 0x565098d45b9a in bio_filter_in_read (bio=0x7f024800b460,
>>   in=0x7f02480492a3 "", inlen=5) at ssl_engine_io.c:483
>> #13 0x7f02736b014c in BIO_read ()
>>  from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
>> #14 0x7f0273a13c92 in ?? () from
>> /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
>> #15 0x7f0273a1548d in ?? () from
>> /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
>> #16 0x7f0273a12024 in ?? () from
>> /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
>> #17 0x565098d469f3 in ssl_io_input_read (inctx=0x7f022c0035b8,
>>   buf=0x7f022c003600 "GET
>> /media/image/07/3c/c2/4612_13721_160192280322.jpeg 

Re: release v1.9.2

[Stefan Priebe - Profihost AG]

Hi Stefan,

yes this seems to correct BUT i'm not sure i the test was long enough
where i hadn't a segfault. I'll rerun a test with that version. To
verify this was no just a "fault".

Greets,
Stefan
Am 05.03.2017 um 14:34 schrieb Stefan Eissing:
> Thanks. I try to summarize:
> 
> - we did see this rarely with unpatched v1.9.2 and Yann's mpm patch v??
> - we still see this rarely with the patch adding mutex to the main conn 
> allocator (so this seems not to change anything)
> - we did not see this with v1.9.2 and Yann's patch on ptrans version  ??
> 
> Is this correct?
> 
>> Am 04.03.2017 um 22:34 schrieb Stefan Priebe - Profihost AG 
>> :
>>
>> Hi Stefan,
>>
>> current trace - not sure whether this is http2 related at all:
>>
>> Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
>> Program terminated with signal SIGSEGV, Segmentation fault.
>> #0  allocator_free (node=0x0, allocator=0x7fbf4c05a410)
>>at memory/unix/apr_pools.c:381
>> #0  allocator_free (node=0x0, allocator=0x7fbf4c05a410)
>>at memory/unix/apr_pools.c:381
>> #1  apr_pool_clear (pool=0x7fbf4c04f888) at memory/unix/apr_pools.c:793
>> #2  0x5642878c2818 in ap_push_pool (queue_info=0x0,
>>pool_to_recycle=0x7fbf4c05a418) at fdqueue.c:234
>> #3  0x5642878bdb5a in process_lingering_close (cs=0x7fbf4c04fb18,
>>pfd=0x5642886c7078) at event.c:1513
>> #4  0x5642878c1690 in listener_thread (thd=0x0, dummy=0x549eb52311a6f)
>>at event.c:1837
>> #5  0x7fbf5f2940a4 in start_thread ()
>>   from /lib/x86_64-linux-gnu/libpthread.so.0
>> #6  0x7fbf5efc962d in clone () from /lib/x86_64-linux-gnu/libc.so.6
>>
>> Stefan
>>
>>> Am 03.03.2017 um 21:02 schrieb Stefan Priebe - Profihost AG:
>>> Hi Stefan,
>>>
>>> live. Sorry for the late reply.
>>>
>>> Stefan
>>>
 Am 28.02.2017 um 11:49 schrieb Stefan Eissing:
 Meh, my mistake. Sorry about that. Did not cleanup properly. Dare you with 
 an improved version:





> Am 28.02.2017 um 08:41 schrieb Stefan Priebe - Profihost AG 
> :
>
> That one breaks everyting. Multiple crashes per second.
>
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
> Program terminated with signal SIGABRT, Aborted.
> #0  0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> #0  0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x7f02724eb448 in abort () from /lib/x86_64-linux-gnu/libc.so.6
> #2  0x7f02724e3266 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #3  0x7f02724e3312 in __assert_fail () from
> /lib/x86_64-linux-gnu/libc.so.6
> #4  0x7f027287062f in __pthread_tpp_change_priority ()
>  from /lib/x86_64-linux-gnu/libpthread.so.0
> #5  0x7f0272865e9f in __pthread_mutex_lock_full ()
>  from /lib/x86_64-linux-gnu/libpthread.so.0
> #6  0x7f0272a98db8 in allocator_alloc (in_size=in_size@entry=8032,
>   allocator=0x7f025c03f3c0) at memory/unix/apr_pools.c:244
> #7  apr_allocator_alloc (allocator=0x7f025c03f3c0, size=size@entry=8032)
>   at memory/unix/apr_pools.c:438
> #8  0x7f0272cbcac4 in apr_bucket_alloc (size=8032, size@entry=8000,
>   list=0x7f022c0008e8) at buckets/apr_buckets_alloc.c:157
> #9  0x7f0272cbdca2 in socket_bucket_read (a=0x7f022c000b08,
>   str=0x7f02627a87b8, len=0x7f02627a87c0, block=)
>   at buckets/apr_buckets_socket.c:34
> #10 0x565098cf1fb1 in ap_core_input_filter (f=0x7f022c0056b0,
>   b=0x7f022c005630, mode=, block=APR_NONBLOCK_READ,
>   readbytes=5) at core_filters.c:235
> #11 0x565098d3aaca in logio_in_filter (f=,
>   bb=0x7f022c005630, mode=, block=,
>   readbytes=) at mod_logio.c:165
> #12 0x565098d45b9a in bio_filter_in_read (bio=0x7f024800b460,
>   in=0x7f02480492a3 "", inlen=5) at ssl_engine_io.c:483
> #13 0x7f02736b014c in BIO_read ()
>  from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
> #14 0x7f0273a13c92 in ?? () from
> /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
> #15 0x7f0273a1548d in ?? () from
> /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
> #16 0x7f0273a12024 in ?? () from
> /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
> #17 0x565098d469f3 in ssl_io_input_read (inctx=0x7f022c0035b8,
>   buf=0x7f022c003600 "GET
> /media/image/07/3c/c2/4612_13721_160192280322.jpeg HTTP/1.1\r\nHost:
> www.onlinestore.it\r\nUser-Agent: curl/7.15+ (x64-criteo) libcurl/7.15+
> OpenSSL zlib libidn\r\nAccept: */*\r\n\r\n", len=0x7f02627a8b38)
>   at ssl_engine_io.c:614
> #18 0x565098d493ec in ssl_io_filter_input (f=0x7f022c005608,
>   bb=0x7f022c006dd0, mode=, block=,
>   readbytes=8000) at ssl_engine_io.c:1474
> #19 0x565098d5cd85 in 

Re: release v1.9.2

[Stefan Eissing]

Thanks. I try to summarize:

- we did see this rarely with unpatched v1.9.2 and Yann's mpm patch v??
- we still see this rarely with the patch adding mutex to the main conn 
allocator (so this seems not to change anything)
- we did not see this with v1.9.2 and Yann's patch on ptrans version  ??

Is this correct?

> Am 04.03.2017 um 22:34 schrieb Stefan Priebe - Profihost AG 
> :
> 
> Hi Stefan,
> 
> current trace - not sure whether this is http2 related at all:
> 
> Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  allocator_free (node=0x0, allocator=0x7fbf4c05a410)
>at memory/unix/apr_pools.c:381
> #0  allocator_free (node=0x0, allocator=0x7fbf4c05a410)
>at memory/unix/apr_pools.c:381
> #1  apr_pool_clear (pool=0x7fbf4c04f888) at memory/unix/apr_pools.c:793
> #2  0x5642878c2818 in ap_push_pool (queue_info=0x0,
>pool_to_recycle=0x7fbf4c05a418) at fdqueue.c:234
> #3  0x5642878bdb5a in process_lingering_close (cs=0x7fbf4c04fb18,
>pfd=0x5642886c7078) at event.c:1513
> #4  0x5642878c1690 in listener_thread (thd=0x0, dummy=0x549eb52311a6f)
>at event.c:1837
> #5  0x7fbf5f2940a4 in start_thread ()
>   from /lib/x86_64-linux-gnu/libpthread.so.0
> #6  0x7fbf5efc962d in clone () from /lib/x86_64-linux-gnu/libc.so.6
> 
> Stefan
> 
>> Am 03.03.2017 um 21:02 schrieb Stefan Priebe - Profihost AG:
>> Hi Stefan,
>> 
>> live. Sorry for the late reply.
>> 
>> Stefan
>> 
>>> Am 28.02.2017 um 11:49 schrieb Stefan Eissing:
>>> Meh, my mistake. Sorry about that. Did not cleanup properly. Dare you with 
>>> an improved version:
>>> 
>>> 
>>> 
>>> 
>>> 
 Am 28.02.2017 um 08:41 schrieb Stefan Priebe - Profihost AG 
 :
 
 That one breaks everyting. Multiple crashes per second.
 
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
 Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
 Program terminated with signal SIGABRT, Aborted.
 #0  0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
 #0  0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
 #1  0x7f02724eb448 in abort () from /lib/x86_64-linux-gnu/libc.so.6
 #2  0x7f02724e3266 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
 #3  0x7f02724e3312 in __assert_fail () from
 /lib/x86_64-linux-gnu/libc.so.6
 #4  0x7f027287062f in __pthread_tpp_change_priority ()
  from /lib/x86_64-linux-gnu/libpthread.so.0
 #5  0x7f0272865e9f in __pthread_mutex_lock_full ()
  from /lib/x86_64-linux-gnu/libpthread.so.0
 #6  0x7f0272a98db8 in allocator_alloc (in_size=in_size@entry=8032,
   allocator=0x7f025c03f3c0) at memory/unix/apr_pools.c:244
 #7  apr_allocator_alloc (allocator=0x7f025c03f3c0, size=size@entry=8032)
   at memory/unix/apr_pools.c:438
 #8  0x7f0272cbcac4 in apr_bucket_alloc (size=8032, size@entry=8000,
   list=0x7f022c0008e8) at buckets/apr_buckets_alloc.c:157
 #9  0x7f0272cbdca2 in socket_bucket_read (a=0x7f022c000b08,
   str=0x7f02627a87b8, len=0x7f02627a87c0, block=)
   at buckets/apr_buckets_socket.c:34
 #10 0x565098cf1fb1 in ap_core_input_filter (f=0x7f022c0056b0,
   b=0x7f022c005630, mode=, block=APR_NONBLOCK_READ,
   readbytes=5) at core_filters.c:235
 #11 0x565098d3aaca in logio_in_filter (f=,
   bb=0x7f022c005630, mode=, block=,
   readbytes=) at mod_logio.c:165
 #12 0x565098d45b9a in bio_filter_in_read (bio=0x7f024800b460,
   in=0x7f02480492a3 "", inlen=5) at ssl_engine_io.c:483
 #13 0x7f02736b014c in BIO_read ()
  from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
 #14 0x7f0273a13c92 in ?? () from
 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
 #15 0x7f0273a1548d in ?? () from
 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
 #16 0x7f0273a12024 in ?? () from
 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
 #17 0x565098d469f3 in ssl_io_input_read (inctx=0x7f022c0035b8,
   buf=0x7f022c003600 "GET
 /media/image/07/3c/c2/4612_13721_160192280322.jpeg HTTP/1.1\r\nHost:
 www.onlinestore.it\r\nUser-Agent: curl/7.15+ (x64-criteo) libcurl/7.15+
 OpenSSL zlib libidn\r\nAccept: */*\r\n\r\n", len=0x7f02627a8b38)
   at ssl_engine_io.c:614
 #18 0x565098d493ec in ssl_io_filter_input (f=0x7f022c005608,
   bb=0x7f022c006dd0, mode=, block=,
   readbytes=8000) at ssl_engine_io.c:1474
 #19 0x565098d5cd85 in h2_filter_core_input (f=0x7f022c005980,
   brigade=0x7f022c006dd0, mode=738225624, block=APR_NONBLOCK_READ,
   readbytes=8000) at h2_filter.c:149
 #20 0x565098d6809b in h2_session_read (session=0x7f022c006920,
   block=) at h2_session.c:1440
 #21 0x565098d6b97f in h2_session_process (session=0x7f022c006920,
   

Re: release v1.9.2

[Stefan Priebe - Profihost AG]

Hi Stefan,

current trace - not sure whether this is http2 related at all:

Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  allocator_free (node=0x0, allocator=0x7fbf4c05a410)
at memory/unix/apr_pools.c:381
#0  allocator_free (node=0x0, allocator=0x7fbf4c05a410)
at memory/unix/apr_pools.c:381
#1  apr_pool_clear (pool=0x7fbf4c04f888) at memory/unix/apr_pools.c:793
#2  0x5642878c2818 in ap_push_pool (queue_info=0x0,
pool_to_recycle=0x7fbf4c05a418) at fdqueue.c:234
#3  0x5642878bdb5a in process_lingering_close (cs=0x7fbf4c04fb18,
pfd=0x5642886c7078) at event.c:1513
#4  0x5642878c1690 in listener_thread (thd=0x0, dummy=0x549eb52311a6f)
at event.c:1837
#5  0x7fbf5f2940a4 in start_thread ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#6  0x7fbf5efc962d in clone () from /lib/x86_64-linux-gnu/libc.so.6

Stefan

Am 03.03.2017 um 21:02 schrieb Stefan Priebe - Profihost AG:
> Hi Stefan,
> 
> live. Sorry for the late reply.
> 
> Stefan
> 
> Am 28.02.2017 um 11:49 schrieb Stefan Eissing:
>> Meh, my mistake. Sorry about that. Did not cleanup properly. Dare you with 
>> an improved version:
>>
>>
>>
>>
>>
>>> Am 28.02.2017 um 08:41 schrieb Stefan Priebe - Profihost AG 
>>> :
>>>
>>> That one breaks everyting. Multiple crashes per second.
>>>
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>>> Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
>>> Program terminated with signal SIGABRT, Aborted.
>>> #0  0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
>>> #0  0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
>>> #1  0x7f02724eb448 in abort () from /lib/x86_64-linux-gnu/libc.so.6
>>> #2  0x7f02724e3266 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>>> #3  0x7f02724e3312 in __assert_fail () from
>>> /lib/x86_64-linux-gnu/libc.so.6
>>> #4  0x7f027287062f in __pthread_tpp_change_priority ()
>>>   from /lib/x86_64-linux-gnu/libpthread.so.0
>>> #5  0x7f0272865e9f in __pthread_mutex_lock_full ()
>>>   from /lib/x86_64-linux-gnu/libpthread.so.0
>>> #6  0x7f0272a98db8 in allocator_alloc (in_size=in_size@entry=8032,
>>>allocator=0x7f025c03f3c0) at memory/unix/apr_pools.c:244
>>> #7  apr_allocator_alloc (allocator=0x7f025c03f3c0, size=size@entry=8032)
>>>at memory/unix/apr_pools.c:438
>>> #8  0x7f0272cbcac4 in apr_bucket_alloc (size=8032, size@entry=8000,
>>>list=0x7f022c0008e8) at buckets/apr_buckets_alloc.c:157
>>> #9  0x7f0272cbdca2 in socket_bucket_read (a=0x7f022c000b08,
>>>str=0x7f02627a87b8, len=0x7f02627a87c0, block=)
>>>at buckets/apr_buckets_socket.c:34
>>> #10 0x565098cf1fb1 in ap_core_input_filter (f=0x7f022c0056b0,
>>>b=0x7f022c005630, mode=, block=APR_NONBLOCK_READ,
>>>readbytes=5) at core_filters.c:235
>>> #11 0x565098d3aaca in logio_in_filter (f=,
>>>bb=0x7f022c005630, mode=, block=,
>>>readbytes=) at mod_logio.c:165
>>> #12 0x565098d45b9a in bio_filter_in_read (bio=0x7f024800b460,
>>>in=0x7f02480492a3 "", inlen=5) at ssl_engine_io.c:483
>>> #13 0x7f02736b014c in BIO_read ()
>>>   from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
>>> #14 0x7f0273a13c92 in ?? () from
>>> /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
>>> #15 0x7f0273a1548d in ?? () from
>>> /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
>>> #16 0x7f0273a12024 in ?? () from
>>> /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
>>> #17 0x565098d469f3 in ssl_io_input_read (inctx=0x7f022c0035b8,
>>>buf=0x7f022c003600 "GET
>>> /media/image/07/3c/c2/4612_13721_160192280322.jpeg HTTP/1.1\r\nHost:
>>> www.onlinestore.it\r\nUser-Agent: curl/7.15+ (x64-criteo) libcurl/7.15+
>>> OpenSSL zlib libidn\r\nAccept: */*\r\n\r\n", len=0x7f02627a8b38)
>>>at ssl_engine_io.c:614
>>> #18 0x565098d493ec in ssl_io_filter_input (f=0x7f022c005608,
>>>bb=0x7f022c006dd0, mode=, block=,
>>>readbytes=8000) at ssl_engine_io.c:1474
>>> #19 0x565098d5cd85 in h2_filter_core_input (f=0x7f022c005980,
>>>brigade=0x7f022c006dd0, mode=738225624, block=APR_NONBLOCK_READ,
>>>readbytes=8000) at h2_filter.c:149
>>> #20 0x565098d6809b in h2_session_read (session=0x7f022c006920,
>>>block=) at h2_session.c:1440
>>> #21 0x565098d6b97f in h2_session_process (session=0x7f022c006920,
>>>async=3964) at h2_session.c:2074
>>> #22 0x565098d5b84e in h2_conn_run (ctx=,
>>> c=0x7f025c03f7d8)
>>>at h2_conn.c:218
>>> #23 0x565098d5e551 in h2_h2_process_conn (c=0x7f025c03f7d8) at
>>> h2_h2.c:658
>>> #24 0x565098d00fd0 in ap_run_process_connection (c=0x7f025c03f7d8)
>>>at connection.c:42
>>> #25 0x565098d9b6d0 in process_socket (my_thread_num=,
>>>my_child_num=, cs=0x7f025c03f748, sock=,
>>>p=, thd=) at event.c:1134
>>> #26 worker_thread (thd=0xf5e, dummy=0xf7c) at 

Re: release v1.9.2

[Stefan Priebe - Profihost AG]

Hi Stefan,

live. Sorry for the late reply.

Stefan

Am 28.02.2017 um 11:49 schrieb Stefan Eissing:
> Meh, my mistake. Sorry about that. Did not cleanup properly. Dare you with an 
> improved version:
> 
> 
> 
> 
> 
>> Am 28.02.2017 um 08:41 schrieb Stefan Priebe - Profihost AG 
>> :
>>
>> That one breaks everyting. Multiple crashes per second.
>>
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>> Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
>> Program terminated with signal SIGABRT, Aborted.
>> #0  0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
>> #0  0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
>> #1  0x7f02724eb448 in abort () from /lib/x86_64-linux-gnu/libc.so.6
>> #2  0x7f02724e3266 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>> #3  0x7f02724e3312 in __assert_fail () from
>> /lib/x86_64-linux-gnu/libc.so.6
>> #4  0x7f027287062f in __pthread_tpp_change_priority ()
>>   from /lib/x86_64-linux-gnu/libpthread.so.0
>> #5  0x7f0272865e9f in __pthread_mutex_lock_full ()
>>   from /lib/x86_64-linux-gnu/libpthread.so.0
>> #6  0x7f0272a98db8 in allocator_alloc (in_size=in_size@entry=8032,
>>allocator=0x7f025c03f3c0) at memory/unix/apr_pools.c:244
>> #7  apr_allocator_alloc (allocator=0x7f025c03f3c0, size=size@entry=8032)
>>at memory/unix/apr_pools.c:438
>> #8  0x7f0272cbcac4 in apr_bucket_alloc (size=8032, size@entry=8000,
>>list=0x7f022c0008e8) at buckets/apr_buckets_alloc.c:157
>> #9  0x7f0272cbdca2 in socket_bucket_read (a=0x7f022c000b08,
>>str=0x7f02627a87b8, len=0x7f02627a87c0, block=)
>>at buckets/apr_buckets_socket.c:34
>> #10 0x565098cf1fb1 in ap_core_input_filter (f=0x7f022c0056b0,
>>b=0x7f022c005630, mode=, block=APR_NONBLOCK_READ,
>>readbytes=5) at core_filters.c:235
>> #11 0x565098d3aaca in logio_in_filter (f=,
>>bb=0x7f022c005630, mode=, block=,
>>readbytes=) at mod_logio.c:165
>> #12 0x565098d45b9a in bio_filter_in_read (bio=0x7f024800b460,
>>in=0x7f02480492a3 "", inlen=5) at ssl_engine_io.c:483
>> #13 0x7f02736b014c in BIO_read ()
>>   from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
>> #14 0x7f0273a13c92 in ?? () from
>> /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
>> #15 0x7f0273a1548d in ?? () from
>> /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
>> #16 0x7f0273a12024 in ?? () from
>> /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
>> #17 0x565098d469f3 in ssl_io_input_read (inctx=0x7f022c0035b8,
>>buf=0x7f022c003600 "GET
>> /media/image/07/3c/c2/4612_13721_160192280322.jpeg HTTP/1.1\r\nHost:
>> www.onlinestore.it\r\nUser-Agent: curl/7.15+ (x64-criteo) libcurl/7.15+
>> OpenSSL zlib libidn\r\nAccept: */*\r\n\r\n", len=0x7f02627a8b38)
>>at ssl_engine_io.c:614
>> #18 0x565098d493ec in ssl_io_filter_input (f=0x7f022c005608,
>>bb=0x7f022c006dd0, mode=, block=,
>>readbytes=8000) at ssl_engine_io.c:1474
>> #19 0x565098d5cd85 in h2_filter_core_input (f=0x7f022c005980,
>>brigade=0x7f022c006dd0, mode=738225624, block=APR_NONBLOCK_READ,
>>readbytes=8000) at h2_filter.c:149
>> #20 0x565098d6809b in h2_session_read (session=0x7f022c006920,
>>block=) at h2_session.c:1440
>> #21 0x565098d6b97f in h2_session_process (session=0x7f022c006920,
>>async=3964) at h2_session.c:2074
>> #22 0x565098d5b84e in h2_conn_run (ctx=,
>> c=0x7f025c03f7d8)
>>at h2_conn.c:218
>> #23 0x565098d5e551 in h2_h2_process_conn (c=0x7f025c03f7d8) at
>> h2_h2.c:658
>> #24 0x565098d00fd0 in ap_run_process_connection (c=0x7f025c03f7d8)
>>at connection.c:42
>> #25 0x565098d9b6d0 in process_socket (my_thread_num=,
>>my_child_num=, cs=0x7f025c03f748, sock=,
>>p=, thd=) at event.c:1134
>> #26 worker_thread (thd=0xf5e, dummy=0xf7c) at event.c:2137
>> #27 0x7f02728680a4 in start_thread ()
>>   from /lib/x86_64-linux-gnu/libpthread.so.0
>> #28 0x7f027259d62d in clone () from /lib/x86_64-linux-gnu/libc.so.6
>> (gdb) (gdb) quit
>> Reading symbols from /usr/local/apache/bin/httpd...Reading symbols from
>> /usr/lib/debug//usr/local/apache2/bin/httpd...done.
>> done.
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>> Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
>> Program terminated with signal SIGABRT, Aborted.
>> #0  0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
>> #0  0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
>> #1  0x7f02724eb448 in abort () from /lib/x86_64-linux-gnu/libc.so.6
>> #2  0x7f02724e3266 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>> #3  0x7f02724e3312 in __assert_fail () from
>> /lib/x86_64-linux-gnu/libc.so.6
>> #4  0x7f027287062f in __pthread_tpp_change_priority ()
>>   from /lib/x86_64-linux-gnu/libpthread.so.0
>> #5  

Re: release v1.9.2

[Stefan Eissing]

Meh, my mistake. Sorry about that. Did not cleanup properly. Dare you with an 
improved version:



h2_192_alloc_mutex_v2.diff
Description: Binary data


> Am 28.02.2017 um 08:41 schrieb Stefan Priebe - Profihost AG 
> :
> 
> That one breaks everyting. Multiple crashes per second.
> 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
> Program terminated with signal SIGABRT, Aborted.
> #0  0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> #0  0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x7f02724eb448 in abort () from /lib/x86_64-linux-gnu/libc.so.6
> #2  0x7f02724e3266 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #3  0x7f02724e3312 in __assert_fail () from
> /lib/x86_64-linux-gnu/libc.so.6
> #4  0x7f027287062f in __pthread_tpp_change_priority ()
>   from /lib/x86_64-linux-gnu/libpthread.so.0
> #5  0x7f0272865e9f in __pthread_mutex_lock_full ()
>   from /lib/x86_64-linux-gnu/libpthread.so.0
> #6  0x7f0272a98db8 in allocator_alloc (in_size=in_size@entry=8032,
>allocator=0x7f025c03f3c0) at memory/unix/apr_pools.c:244
> #7  apr_allocator_alloc (allocator=0x7f025c03f3c0, size=size@entry=8032)
>at memory/unix/apr_pools.c:438
> #8  0x7f0272cbcac4 in apr_bucket_alloc (size=8032, size@entry=8000,
>list=0x7f022c0008e8) at buckets/apr_buckets_alloc.c:157
> #9  0x7f0272cbdca2 in socket_bucket_read (a=0x7f022c000b08,
>str=0x7f02627a87b8, len=0x7f02627a87c0, block=)
>at buckets/apr_buckets_socket.c:34
> #10 0x565098cf1fb1 in ap_core_input_filter (f=0x7f022c0056b0,
>b=0x7f022c005630, mode=, block=APR_NONBLOCK_READ,
>readbytes=5) at core_filters.c:235
> #11 0x565098d3aaca in logio_in_filter (f=,
>bb=0x7f022c005630, mode=, block=,
>readbytes=) at mod_logio.c:165
> #12 0x565098d45b9a in bio_filter_in_read (bio=0x7f024800b460,
>in=0x7f02480492a3 "", inlen=5) at ssl_engine_io.c:483
> #13 0x7f02736b014c in BIO_read ()
>   from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
> #14 0x7f0273a13c92 in ?? () from
> /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
> #15 0x7f0273a1548d in ?? () from
> /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
> #16 0x7f0273a12024 in ?? () from
> /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
> #17 0x565098d469f3 in ssl_io_input_read (inctx=0x7f022c0035b8,
>buf=0x7f022c003600 "GET
> /media/image/07/3c/c2/4612_13721_160192280322.jpeg HTTP/1.1\r\nHost:
> www.onlinestore.it\r\nUser-Agent: curl/7.15+ (x64-criteo) libcurl/7.15+
> OpenSSL zlib libidn\r\nAccept: */*\r\n\r\n", len=0x7f02627a8b38)
>at ssl_engine_io.c:614
> #18 0x565098d493ec in ssl_io_filter_input (f=0x7f022c005608,
>bb=0x7f022c006dd0, mode=, block=,
>readbytes=8000) at ssl_engine_io.c:1474
> #19 0x565098d5cd85 in h2_filter_core_input (f=0x7f022c005980,
>brigade=0x7f022c006dd0, mode=738225624, block=APR_NONBLOCK_READ,
>readbytes=8000) at h2_filter.c:149
> #20 0x565098d6809b in h2_session_read (session=0x7f022c006920,
>block=) at h2_session.c:1440
> #21 0x565098d6b97f in h2_session_process (session=0x7f022c006920,
>async=3964) at h2_session.c:2074
> #22 0x565098d5b84e in h2_conn_run (ctx=,
> c=0x7f025c03f7d8)
>at h2_conn.c:218
> #23 0x565098d5e551 in h2_h2_process_conn (c=0x7f025c03f7d8) at
> h2_h2.c:658
> #24 0x565098d00fd0 in ap_run_process_connection (c=0x7f025c03f7d8)
>at connection.c:42
> #25 0x565098d9b6d0 in process_socket (my_thread_num=,
>my_child_num=, cs=0x7f025c03f748, sock=,
>p=, thd=) at event.c:1134
> #26 worker_thread (thd=0xf5e, dummy=0xf7c) at event.c:2137
> #27 0x7f02728680a4 in start_thread ()
>   from /lib/x86_64-linux-gnu/libpthread.so.0
> #28 0x7f027259d62d in clone () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) (gdb) quit
> Reading symbols from /usr/local/apache/bin/httpd...Reading symbols from
> /usr/lib/debug//usr/local/apache2/bin/httpd...done.
> done.
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
> Program terminated with signal SIGABRT, Aborted.
> #0  0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> #0  0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x7f02724eb448 in abort () from /lib/x86_64-linux-gnu/libc.so.6
> #2  0x7f02724e3266 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #3  0x7f02724e3312 in __assert_fail () from
> /lib/x86_64-linux-gnu/libc.so.6
> #4  0x7f027287062f in __pthread_tpp_change_priority ()
>   from /lib/x86_64-linux-gnu/libpthread.so.0
> #5  0x7f0272865e9f in __pthread_mutex_lock_full ()
>   from /lib/x86_64-linux-gnu/libpthread.so.0
> #6  0x7f0272a98db8 in allocator_alloc 

Re: release v1.9.2

[Stefan Priebe - Profihost AG]

That one breaks everyting. Multiple crashes per second.

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
Program terminated with signal SIGABRT, Aborted.
#0  0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#0  0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f02724eb448 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x7f02724e3266 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x7f02724e3312 in __assert_fail () from
/lib/x86_64-linux-gnu/libc.so.6
#4  0x7f027287062f in __pthread_tpp_change_priority ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#5  0x7f0272865e9f in __pthread_mutex_lock_full ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#6  0x7f0272a98db8 in allocator_alloc (in_size=in_size@entry=8032,
allocator=0x7f025c03f3c0) at memory/unix/apr_pools.c:244
#7  apr_allocator_alloc (allocator=0x7f025c03f3c0, size=size@entry=8032)
at memory/unix/apr_pools.c:438
#8  0x7f0272cbcac4 in apr_bucket_alloc (size=8032, size@entry=8000,
list=0x7f022c0008e8) at buckets/apr_buckets_alloc.c:157
#9  0x7f0272cbdca2 in socket_bucket_read (a=0x7f022c000b08,
str=0x7f02627a87b8, len=0x7f02627a87c0, block=)
at buckets/apr_buckets_socket.c:34
#10 0x565098cf1fb1 in ap_core_input_filter (f=0x7f022c0056b0,
b=0x7f022c005630, mode=, block=APR_NONBLOCK_READ,
readbytes=5) at core_filters.c:235
#11 0x565098d3aaca in logio_in_filter (f=,
bb=0x7f022c005630, mode=, block=,
readbytes=) at mod_logio.c:165
#12 0x565098d45b9a in bio_filter_in_read (bio=0x7f024800b460,
in=0x7f02480492a3 "", inlen=5) at ssl_engine_io.c:483
#13 0x7f02736b014c in BIO_read ()
   from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#14 0x7f0273a13c92 in ?? () from
/usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
#15 0x7f0273a1548d in ?? () from
/usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
#16 0x7f0273a12024 in ?? () from
/usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
#17 0x565098d469f3 in ssl_io_input_read (inctx=0x7f022c0035b8,
buf=0x7f022c003600 "GET
/media/image/07/3c/c2/4612_13721_160192280322.jpeg HTTP/1.1\r\nHost:
www.onlinestore.it\r\nUser-Agent: curl/7.15+ (x64-criteo) libcurl/7.15+
OpenSSL zlib libidn\r\nAccept: */*\r\n\r\n", len=0x7f02627a8b38)
at ssl_engine_io.c:614
#18 0x565098d493ec in ssl_io_filter_input (f=0x7f022c005608,
bb=0x7f022c006dd0, mode=, block=,
readbytes=8000) at ssl_engine_io.c:1474
#19 0x565098d5cd85 in h2_filter_core_input (f=0x7f022c005980,
brigade=0x7f022c006dd0, mode=738225624, block=APR_NONBLOCK_READ,
readbytes=8000) at h2_filter.c:149
#20 0x565098d6809b in h2_session_read (session=0x7f022c006920,
block=) at h2_session.c:1440
#21 0x565098d6b97f in h2_session_process (session=0x7f022c006920,
async=3964) at h2_session.c:2074
#22 0x565098d5b84e in h2_conn_run (ctx=,
c=0x7f025c03f7d8)
at h2_conn.c:218
#23 0x565098d5e551 in h2_h2_process_conn (c=0x7f025c03f7d8) at
h2_h2.c:658
#24 0x565098d00fd0 in ap_run_process_connection (c=0x7f025c03f7d8)
at connection.c:42
#25 0x565098d9b6d0 in process_socket (my_thread_num=,
my_child_num=, cs=0x7f025c03f748, sock=,
p=, thd=) at event.c:1134
#26 worker_thread (thd=0xf5e, dummy=0xf7c) at event.c:2137
#27 0x7f02728680a4 in start_thread ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#28 0x7f027259d62d in clone () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) (gdb) quit
Reading symbols from /usr/local/apache/bin/httpd...Reading symbols from
/usr/lib/debug//usr/local/apache2/bin/httpd...done.
done.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
Program terminated with signal SIGABRT, Aborted.
#0  0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#0  0x7f02724ea067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f02724eb448 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x7f02724e3266 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x7f02724e3312 in __assert_fail () from
/lib/x86_64-linux-gnu/libc.so.6
#4  0x7f027287062f in __pthread_tpp_change_priority ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#5  0x7f0272865e9f in __pthread_mutex_lock_full ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#6  0x7f0272a98db8 in allocator_alloc (in_size=in_size@entry=8032,
allocator=0x7f025c03d320) at memory/unix/apr_pools.c:244
#7  apr_allocator_alloc (allocator=0x7f025c03d320, size=size@entry=8032)
at memory/unix/apr_pools.c:438
#8  0x7f0272cbcac4 in apr_bucket_alloc (size=8032, size@entry=8000,
list=0x7f02340008e8) at buckets/apr_buckets_alloc.c:157
#9  0x7f0272cbdca2 in socket_bucket_read (a=0x7f0234000b08,

Re: release v1.9.2

[Stefan Eissing]

Damnit. Can you try the attached patch on top of mod_http2 v1.9.2? This one 
sets a mutex on the main connection allocator if missing and is pretty close to 
the version we ran successfully with on your site for days.

Thanks again!

-Stefan



h2_192_alloc_mutex.diff
Description: Binary data

> Am 27.02.2017 um 16:22 schrieb Stefan Priebe - Profihost AG 
> :
> 
> Hi Stefan,
> 
> two new crashes here.
> 
> Reading symbols from /usr/local/apache/bin/httpd...Reading symbols from
> /usr/lib/debug//usr/local/apache2/bin/httpd...done.
> done.
> (gdb) (gdb) quit
> Reading symbols from /usr/local/apache/bin/httpd...Reading symbols from
> /usr/lib/debug//usr/local/apache2/bin/httpd...done.
> done.
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  allocator_free (node=0x0, allocator=0x7f458005a320)
>at memory/unix/apr_pools.c:381
> #0  allocator_free (node=0x0, allocator=0x7f458005a320)
>at memory/unix/apr_pools.c:381
> #1  apr_pool_clear (pool=0x7f458004bec8) at memory/unix/apr_pools.c:793
> #2  0x560ce83e5718 in ap_push_pool (queue_info=0x0,
>pool_to_recycle=0x7f458005a328) at fdqueue.c:234
> #3  0x560ce83e0a5a in process_lingering_close (cs=0x7f458004c158,
>pfd=0x560ce8b8dda8) at event.c:1513
> #4  0x560ce83e4590 in listener_thread (thd=0x0, dummy=0x5497f5242585c)
>at event.c:1837
> #5  0x7f45967610a4 in start_thread ()
>   from /lib/x86_64-linux-gnu/libpthread.so.0
> #6  0x7f459649662d in clone () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) (gdb) quit
> 
> 
> Reading symbols from /usr/local/apache/bin/httpd...Reading symbols from
> /usr/lib/debug//usr/local/apache2/bin/httpd...done.
> done.
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  allocator_free (node=0x0, allocator=0x7f4580062840)
>at memory/unix/apr_pools.c:381
> #0  allocator_free (node=0x0, allocator=0x7f4580062840)
>at memory/unix/apr_pools.c:381
> #1  apr_pool_clear (pool=0x7f4580069188) at memory/unix/apr_pools.c:793
> #2  0x560ce83e5718 in ap_push_pool (queue_info=0x0,
>pool_to_recycle=0x7f4580062848) at fdqueue.c:234
> #3  0x560ce83e0a5a in process_lingering_close (cs=0x7f4580069418,
>pfd=0x560ce8b8dda8) at event.c:1513
> #4  0x560ce83e4590 in listener_thread (thd=0x0, dummy=0x549845279ce62)
>at event.c:1837
> #5  0x7f45967610a4 in start_thread ()
>   from /lib/x86_64-linux-gnu/libpthread.so.0
> #6  0x7f459649662d in clone () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) (gdb) quit
> 
> Stefan
> Am 26.02.2017 um 19:46 schrieb Stefan Priebe - Profihost AG:
>> Hi Stefan,
>> 
>> currently everything fine. No segfaults.
>> 
>> Stefan
>> 
>> Am 25.02.2017 um 20:40 schrieb Stefan Priebe - Profihost AG:
>>> Hi Stefan,
>>> Am 25.02.2017 um 13:51 schrieb Stefan Eissing:
 Stefan,
 
 whenever you have time, please deploy 
 https://github.com/icing/mod_h2/releases/tag/v1.9.2
 
 I added an own allocator with mutex to the http/2 main session. That is 
 something of a middle-ground between placing that on the main conn (as we 
 had in the crash free version) and 1.9.1 behaviour. Thanks!
>>> 
>>> done. But please keep in mind that this crash might be very rare and
>>> might even have happened with v1.9.0 if we've waited more time.
>>> 
>>> Greets,
>>> Stefan
>>> 
 -Stefan
 
> Am 24.02.2017 um 19:31 schrieb Stefan Priebe - Profihost AG 
> :
> 
> Hi Yann,
> 
> here we go:
> 
> (gdb) p *ipsub
> $1 = {family = 2, sub = {1367753145, 0, 0, 0}, mask = {4294967295,
> 4294967295, 4294967295, 4294967295}}
> 
> (gdb) p *sa
> $2 = {pool = 0x10b500c4ff0b0a, hostname = 0x503040203030102  Cannot access memory at address 0x503040203030102>,
> servname = 0x17d01040405  0x17d01040405>, port = 770, family = 554829073,
> salen = 319177009, ipaddr_len = 570909009, addr_str_len = -2127424399,
> ipaddr_ptr = 0x24f0d15215c1b142,
> next = 0x17160a0982726233, sa = {sin = {sin_family = 6424, sin_port =
> 9498, sin_addr = {s_addr = 690497318},
> sin_zero = "*456789:"}, sin6 = {sin6_family = 6424, sin6_port =
> 9498, sin6_flowinfo = 690497318, sin6_addr = {__in6_u = {
> __u6_addr8 = "*456789:CDEFGHIJ", __u6_addr16 = {13354, 13877,
> 14391, 14905, 17475, 17989, 18503, 19017}, __u6_addr32 = {
>   909456426, 976828471, 1178944579, 1246316615}}},
> sin6_scope_id = 1448432723}, sas = {ss_family = 6424,
> __ss_align = 4195446337656140842,
> __ss_padding =
> 

Re: release v1.9.2

[Stefan Priebe - Profihost AG]

Hi Stefan,

two new crashes here.

Reading symbols from /usr/local/apache/bin/httpd...Reading symbols from
/usr/lib/debug//usr/local/apache2/bin/httpd...done.
done.
(gdb) (gdb) quit
Reading symbols from /usr/local/apache/bin/httpd...Reading symbols from
/usr/lib/debug//usr/local/apache2/bin/httpd...done.
done.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  allocator_free (node=0x0, allocator=0x7f458005a320)
at memory/unix/apr_pools.c:381
#0  allocator_free (node=0x0, allocator=0x7f458005a320)
at memory/unix/apr_pools.c:381
#1  apr_pool_clear (pool=0x7f458004bec8) at memory/unix/apr_pools.c:793
#2  0x560ce83e5718 in ap_push_pool (queue_info=0x0,
pool_to_recycle=0x7f458005a328) at fdqueue.c:234
#3  0x560ce83e0a5a in process_lingering_close (cs=0x7f458004c158,
pfd=0x560ce8b8dda8) at event.c:1513
#4  0x560ce83e4590 in listener_thread (thd=0x0, dummy=0x5497f5242585c)
at event.c:1837
#5  0x7f45967610a4 in start_thread ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#6  0x7f459649662d in clone () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) (gdb) quit


Reading symbols from /usr/local/apache/bin/httpd...Reading symbols from
/usr/lib/debug//usr/local/apache2/bin/httpd...done.
done.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  allocator_free (node=0x0, allocator=0x7f4580062840)
at memory/unix/apr_pools.c:381
#0  allocator_free (node=0x0, allocator=0x7f4580062840)
at memory/unix/apr_pools.c:381
#1  apr_pool_clear (pool=0x7f4580069188) at memory/unix/apr_pools.c:793
#2  0x560ce83e5718 in ap_push_pool (queue_info=0x0,
pool_to_recycle=0x7f4580062848) at fdqueue.c:234
#3  0x560ce83e0a5a in process_lingering_close (cs=0x7f4580069418,
pfd=0x560ce8b8dda8) at event.c:1513
#4  0x560ce83e4590 in listener_thread (thd=0x0, dummy=0x549845279ce62)
at event.c:1837
#5  0x7f45967610a4 in start_thread ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#6  0x7f459649662d in clone () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) (gdb) quit

Stefan
Am 26.02.2017 um 19:46 schrieb Stefan Priebe - Profihost AG:
> Hi Stefan,
> 
> currently everything fine. No segfaults.
> 
> Stefan
> 
> Am 25.02.2017 um 20:40 schrieb Stefan Priebe - Profihost AG:
>> Hi Stefan,
>> Am 25.02.2017 um 13:51 schrieb Stefan Eissing:
>>> Stefan,
>>>
>>> whenever you have time, please deploy 
>>> https://github.com/icing/mod_h2/releases/tag/v1.9.2
>>>
>>> I added an own allocator with mutex to the http/2 main session. That is 
>>> something of a middle-ground between placing that on the main conn (as we 
>>> had in the crash free version) and 1.9.1 behaviour. Thanks!
>>
>> done. But please keep in mind that this crash might be very rare and
>> might even have happened with v1.9.0 if we've waited more time.
>>
>> Greets,
>> Stefan
>>
>>> -Stefan
>>>
 Am 24.02.2017 um 19:31 schrieb Stefan Priebe - Profihost AG 
 :

 Hi Yann,

 here we go:

 (gdb) p *ipsub
 $1 = {family = 2, sub = {1367753145, 0, 0, 0}, mask = {4294967295,
 4294967295, 4294967295, 4294967295}}

 (gdb) p *sa
 $2 = {pool = 0x10b500c4ff0b0a, hostname = 0x503040203030102 >>> Cannot access memory at address 0x503040203030102>,
  servname = 0x17d01040405 >>> 0x17d01040405>, port = 770, family = 554829073,
  salen = 319177009, ipaddr_len = 570909009, addr_str_len = -2127424399,
 ipaddr_ptr = 0x24f0d15215c1b142,
  next = 0x17160a0982726233, sa = {sin = {sin_family = 6424, sin_port =
 9498, sin_addr = {s_addr = 690497318},
  sin_zero = "*456789:"}, sin6 = {sin6_family = 6424, sin6_port =
 9498, sin6_flowinfo = 690497318, sin6_addr = {__in6_u = {
  __u6_addr8 = "*456789:CDEFGHIJ", __u6_addr16 = {13354, 13877,
 14391, 14905, 17475, 17989, 18503, 19017}, __u6_addr32 = {
909456426, 976828471, 1178944579, 1246316615}}},
 sin6_scope_id = 1448432723}, sas = {ss_family = 6424,
  __ss_align = 4195446337656140842,
  __ss_padding =
 "CDEFGHIJSTUVWXYZcdefghijstuvwxyz\203\204\205\206\207\210\211\212\222\223\224\225\226\227\230\231\232\242\243\244\245\246\247\250\251\252\262\263\264\265\266\267\270\271\272\302\303\304\305\306\307\310\311\312\322\323\324\325\326\327\330\331\332\341\342\343\344\345\346\347\350\351\352\361\362\363\364\365\366\367\370\371\372\377\304\000\037\001\000\003"}}}

 (gdb) p *(struct in6_addr *)sa
 $3 = {__in6_u = {__u6_addr8 =
 "\n\v\377\304\000\265\020\000\002\001\003\003\002\004\003\005",
 __u6_addr16 = {2826, 50431, 46336,
  16, 

Re: release v1.9.2

[Stefan Priebe - Profihost AG]

Hi Stefan,

currently everything fine. No segfaults.

Stefan

Am 25.02.2017 um 20:40 schrieb Stefan Priebe - Profihost AG:
> Hi Stefan,
> Am 25.02.2017 um 13:51 schrieb Stefan Eissing:
>> Stefan,
>>
>> whenever you have time, please deploy 
>> https://github.com/icing/mod_h2/releases/tag/v1.9.2
>>
>> I added an own allocator with mutex to the http/2 main session. That is 
>> something of a middle-ground between placing that on the main conn (as we 
>> had in the crash free version) and 1.9.1 behaviour. Thanks!
> 
> done. But please keep in mind that this crash might be very rare and
> might even have happened with v1.9.0 if we've waited more time.
> 
> Greets,
> Stefan
> 
>> -Stefan
>>
>>> Am 24.02.2017 um 19:31 schrieb Stefan Priebe - Profihost AG 
>>> :
>>>
>>> Hi Yann,
>>>
>>> here we go:
>>>
>>> (gdb) p *ipsub
>>> $1 = {family = 2, sub = {1367753145, 0, 0, 0}, mask = {4294967295,
>>> 4294967295, 4294967295, 4294967295}}
>>>
>>> (gdb) p *sa
>>> $2 = {pool = 0x10b500c4ff0b0a, hostname = 0x503040203030102 >> Cannot access memory at address 0x503040203030102>,
>>>  servname = 0x17d01040405 >> 0x17d01040405>, port = 770, family = 554829073,
>>>  salen = 319177009, ipaddr_len = 570909009, addr_str_len = -2127424399,
>>> ipaddr_ptr = 0x24f0d15215c1b142,
>>>  next = 0x17160a0982726233, sa = {sin = {sin_family = 6424, sin_port =
>>> 9498, sin_addr = {s_addr = 690497318},
>>>  sin_zero = "*456789:"}, sin6 = {sin6_family = 6424, sin6_port =
>>> 9498, sin6_flowinfo = 690497318, sin6_addr = {__in6_u = {
>>>  __u6_addr8 = "*456789:CDEFGHIJ", __u6_addr16 = {13354, 13877,
>>> 14391, 14905, 17475, 17989, 18503, 19017}, __u6_addr32 = {
>>>909456426, 976828471, 1178944579, 1246316615}}},
>>> sin6_scope_id = 1448432723}, sas = {ss_family = 6424,
>>>  __ss_align = 4195446337656140842,
>>>  __ss_padding =
>>> "CDEFGHIJSTUVWXYZcdefghijstuvwxyz\203\204\205\206\207\210\211\212\222\223\224\225\226\227\230\231\232\242\243\244\245\246\247\250\251\252\262\263\264\265\266\267\270\271\272\302\303\304\305\306\307\310\311\312\322\323\324\325\326\327\330\331\332\341\342\343\344\345\346\347\350\351\352\361\362\363\364\365\366\367\370\371\372\377\304\000\037\001\000\003"}}}
>>>
>>> (gdb) p *(struct in6_addr *)sa
>>> $3 = {__in6_u = {__u6_addr8 =
>>> "\n\v\377\304\000\265\020\000\002\001\003\003\002\004\003\005",
>>> __u6_addr16 = {2826, 50431, 46336,
>>>  16, 258, 771, 1026, 1283}, __u6_addr32 = {3305048842, 1094912,
>>> 50528514, 84083714}}}
>>>
>>>
>>> Stefan
>>>
>>> Am 24.02.2017 um 14:18 schrieb Yann Ylavic:
 Hi Stefan (Priebe),

 Is IPv6 (really) involved in your network?

 Could you please show up the gdb output of the below ?

 On Fri, Feb 24, 2017 at 2:07 PM, Yann Ylavic  wrote:
>
> 1078 APR_DECLARE(int) apr_ipsubnet_test(apr_ipsubnet_t *ipsub,
> apr_sockaddr_t *sa)
> 1079 {
> 1080 #if APR_HAVE_IPV6
> 1081 /* XXX This line will segv on Win32 build with APR_HAVE_IPV6,
> 1082  * but without the IPV6 drivers installed.
> 1083  */
> 1084 if (sa->family == AF_INET) {
> 1085 if (ipsub->family == AF_INET &&
> 1086 ((sa->sa.sin.sin_addr.s_addr & ipsub->mask[0]) ==
> ipsub->sub[0])) {
> 1087 return 1;
> 1088 }
> 1089 }
> 1090 else if (IN6_IS_ADDR_V4MAPPED((struct in6_addr 
> *)sa->ipaddr_ptr)) {
> 1091 if (ipsub->family == AF_INET &&
> 1092 (((apr_uint32_t *)sa->ipaddr_ptr)[3] &
> ipsub->mask[0]) == ipsub->sub[0]) {
> 1093 return 1;
> 1094 }
> 1095 }

 (gdb) p *ipsub
 (gdb) p *sa
 (gdb) p *(struct in6_addr *)sa

 and possibly more to come...


 Thanks,
 Yann.

>>
>> Stefan Eissing
>>
>> bytes GmbH
>> Hafenstrasse 16
>> 48155 Münster
>> www.greenbytes.de
>>

Re: release v1.9.0

[Stefan Priebe - Profihost AG]

Hi Stefan,
Am 25.02.2017 um 13:51 schrieb Stefan Eissing:
> Stefan,
> 
> whenever you have time, please deploy 
> https://github.com/icing/mod_h2/releases/tag/v1.9.2
> 
> I added an own allocator with mutex to the http/2 main session. That is 
> something of a middle-ground between placing that on the main conn (as we had 
> in the crash free version) and 1.9.1 behaviour. Thanks!

done. But please keep in mind that this crash might be very rare and
might even have happened with v1.9.0 if we've waited more time.

Greets,
Stefan

> -Stefan
> 
>> Am 24.02.2017 um 19:31 schrieb Stefan Priebe - Profihost AG 
>> :
>>
>> Hi Yann,
>>
>> here we go:
>>
>> (gdb) p *ipsub
>> $1 = {family = 2, sub = {1367753145, 0, 0, 0}, mask = {4294967295,
>> 4294967295, 4294967295, 4294967295}}
>>
>> (gdb) p *sa
>> $2 = {pool = 0x10b500c4ff0b0a, hostname = 0x503040203030102 > Cannot access memory at address 0x503040203030102>,
>>  servname = 0x17d01040405 > 0x17d01040405>, port = 770, family = 554829073,
>>  salen = 319177009, ipaddr_len = 570909009, addr_str_len = -2127424399,
>> ipaddr_ptr = 0x24f0d15215c1b142,
>>  next = 0x17160a0982726233, sa = {sin = {sin_family = 6424, sin_port =
>> 9498, sin_addr = {s_addr = 690497318},
>>  sin_zero = "*456789:"}, sin6 = {sin6_family = 6424, sin6_port =
>> 9498, sin6_flowinfo = 690497318, sin6_addr = {__in6_u = {
>>  __u6_addr8 = "*456789:CDEFGHIJ", __u6_addr16 = {13354, 13877,
>> 14391, 14905, 17475, 17989, 18503, 19017}, __u6_addr32 = {
>>909456426, 976828471, 1178944579, 1246316615}}},
>> sin6_scope_id = 1448432723}, sas = {ss_family = 6424,
>>  __ss_align = 4195446337656140842,
>>  __ss_padding =
>> "CDEFGHIJSTUVWXYZcdefghijstuvwxyz\203\204\205\206\207\210\211\212\222\223\224\225\226\227\230\231\232\242\243\244\245\246\247\250\251\252\262\263\264\265\266\267\270\271\272\302\303\304\305\306\307\310\311\312\322\323\324\325\326\327\330\331\332\341\342\343\344\345\346\347\350\351\352\361\362\363\364\365\366\367\370\371\372\377\304\000\037\001\000\003"}}}
>>
>> (gdb) p *(struct in6_addr *)sa
>> $3 = {__in6_u = {__u6_addr8 =
>> "\n\v\377\304\000\265\020\000\002\001\003\003\002\004\003\005",
>> __u6_addr16 = {2826, 50431, 46336,
>>  16, 258, 771, 1026, 1283}, __u6_addr32 = {3305048842, 1094912,
>> 50528514, 84083714}}}
>>
>>
>> Stefan
>>
>> Am 24.02.2017 um 14:18 schrieb Yann Ylavic:
>>> Hi Stefan (Priebe),
>>>
>>> Is IPv6 (really) involved in your network?
>>>
>>> Could you please show up the gdb output of the below ?
>>>
>>> On Fri, Feb 24, 2017 at 2:07 PM, Yann Ylavic  wrote:

 1078 APR_DECLARE(int) apr_ipsubnet_test(apr_ipsubnet_t *ipsub,
 apr_sockaddr_t *sa)
 1079 {
 1080 #if APR_HAVE_IPV6
 1081 /* XXX This line will segv on Win32 build with APR_HAVE_IPV6,
 1082  * but without the IPV6 drivers installed.
 1083  */
 1084 if (sa->family == AF_INET) {
 1085 if (ipsub->family == AF_INET &&
 1086 ((sa->sa.sin.sin_addr.s_addr & ipsub->mask[0]) ==
 ipsub->sub[0])) {
 1087 return 1;
 1088 }
 1089 }
 1090 else if (IN6_IS_ADDR_V4MAPPED((struct in6_addr *)sa->ipaddr_ptr)) 
 {
 1091 if (ipsub->family == AF_INET &&
 1092 (((apr_uint32_t *)sa->ipaddr_ptr)[3] &
 ipsub->mask[0]) == ipsub->sub[0]) {
 1093 return 1;
 1094 }
 1095 }
>>>
>>> (gdb) p *ipsub
>>> (gdb) p *sa
>>> (gdb) p *(struct in6_addr *)sa
>>>
>>> and possibly more to come...
>>>
>>>
>>> Thanks,
>>> Yann.
>>>
> 
> Stefan Eissing
> 
> bytes GmbH
> Hafenstrasse 16
> 48155 Münster
> www.greenbytes.de
> 

Re: release v1.9.0

[Stefan Eissing]

Stefan,

whenever you have time, please deploy 
https://github.com/icing/mod_h2/releases/tag/v1.9.2

I added an own allocator with mutex to the http/2 main session. That is 
something of a middle-ground between placing that on the main conn (as we had 
in the crash free version) and 1.9.1 behaviour. Thanks!

-Stefan

> Am 24.02.2017 um 19:31 schrieb Stefan Priebe - Profihost AG 
> :
> 
> Hi Yann,
> 
> here we go:
> 
> (gdb) p *ipsub
> $1 = {family = 2, sub = {1367753145, 0, 0, 0}, mask = {4294967295,
> 4294967295, 4294967295, 4294967295}}
> 
> (gdb) p *sa
> $2 = {pool = 0x10b500c4ff0b0a, hostname = 0x503040203030102  Cannot access memory at address 0x503040203030102>,
>  servname = 0x17d01040405  0x17d01040405>, port = 770, family = 554829073,
>  salen = 319177009, ipaddr_len = 570909009, addr_str_len = -2127424399,
> ipaddr_ptr = 0x24f0d15215c1b142,
>  next = 0x17160a0982726233, sa = {sin = {sin_family = 6424, sin_port =
> 9498, sin_addr = {s_addr = 690497318},
>  sin_zero = "*456789:"}, sin6 = {sin6_family = 6424, sin6_port =
> 9498, sin6_flowinfo = 690497318, sin6_addr = {__in6_u = {
>  __u6_addr8 = "*456789:CDEFGHIJ", __u6_addr16 = {13354, 13877,
> 14391, 14905, 17475, 17989, 18503, 19017}, __u6_addr32 = {
>909456426, 976828471, 1178944579, 1246316615}}},
> sin6_scope_id = 1448432723}, sas = {ss_family = 6424,
>  __ss_align = 4195446337656140842,
>  __ss_padding =
> "CDEFGHIJSTUVWXYZcdefghijstuvwxyz\203\204\205\206\207\210\211\212\222\223\224\225\226\227\230\231\232\242\243\244\245\246\247\250\251\252\262\263\264\265\266\267\270\271\272\302\303\304\305\306\307\310\311\312\322\323\324\325\326\327\330\331\332\341\342\343\344\345\346\347\350\351\352\361\362\363\364\365\366\367\370\371\372\377\304\000\037\001\000\003"}}}
> 
> (gdb) p *(struct in6_addr *)sa
> $3 = {__in6_u = {__u6_addr8 =
> "\n\v\377\304\000\265\020\000\002\001\003\003\002\004\003\005",
> __u6_addr16 = {2826, 50431, 46336,
>  16, 258, 771, 1026, 1283}, __u6_addr32 = {3305048842, 1094912,
> 50528514, 84083714}}}
> 
> 
> Stefan
> 
> Am 24.02.2017 um 14:18 schrieb Yann Ylavic:
>> Hi Stefan (Priebe),
>> 
>> Is IPv6 (really) involved in your network?
>> 
>> Could you please show up the gdb output of the below ?
>> 
>> On Fri, Feb 24, 2017 at 2:07 PM, Yann Ylavic  wrote:
>>> 
>>> 1078 APR_DECLARE(int) apr_ipsubnet_test(apr_ipsubnet_t *ipsub,
>>> apr_sockaddr_t *sa)
>>> 1079 {
>>> 1080 #if APR_HAVE_IPV6
>>> 1081 /* XXX This line will segv on Win32 build with APR_HAVE_IPV6,
>>> 1082  * but without the IPV6 drivers installed.
>>> 1083  */
>>> 1084 if (sa->family == AF_INET) {
>>> 1085 if (ipsub->family == AF_INET &&
>>> 1086 ((sa->sa.sin.sin_addr.s_addr & ipsub->mask[0]) ==
>>> ipsub->sub[0])) {
>>> 1087 return 1;
>>> 1088 }
>>> 1089 }
>>> 1090 else if (IN6_IS_ADDR_V4MAPPED((struct in6_addr *)sa->ipaddr_ptr)) {
>>> 1091 if (ipsub->family == AF_INET &&
>>> 1092 (((apr_uint32_t *)sa->ipaddr_ptr)[3] &
>>> ipsub->mask[0]) == ipsub->sub[0]) {
>>> 1093 return 1;
>>> 1094 }
>>> 1095 }
>> 
>> (gdb) p *ipsub
>> (gdb) p *sa
>> (gdb) p *(struct in6_addr *)sa
>> 
>> and possibly more to come...
>> 
>> 
>> Thanks,
>> Yann.
>> 

Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

Re: release v1.9.0

[Stefan Priebe - Profihost AG]

Hi Yann,

here we go:

(gdb) p *ipsub
$1 = {family = 2, sub = {1367753145, 0, 0, 0}, mask = {4294967295,
4294967295, 4294967295, 4294967295}}

(gdb) p *sa
$2 = {pool = 0x10b500c4ff0b0a, hostname = 0x503040203030102 ,
  servname = 0x17d01040405 , port = 770, family = 554829073,
  salen = 319177009, ipaddr_len = 570909009, addr_str_len = -2127424399,
ipaddr_ptr = 0x24f0d15215c1b142,
  next = 0x17160a0982726233, sa = {sin = {sin_family = 6424, sin_port =
9498, sin_addr = {s_addr = 690497318},
  sin_zero = "*456789:"}, sin6 = {sin6_family = 6424, sin6_port =
9498, sin6_flowinfo = 690497318, sin6_addr = {__in6_u = {
  __u6_addr8 = "*456789:CDEFGHIJ", __u6_addr16 = {13354, 13877,
14391, 14905, 17475, 17989, 18503, 19017}, __u6_addr32 = {
909456426, 976828471, 1178944579, 1246316615}}},
sin6_scope_id = 1448432723}, sas = {ss_family = 6424,
  __ss_align = 4195446337656140842,
  __ss_padding =
"CDEFGHIJSTUVWXYZcdefghijstuvwxyz\203\204\205\206\207\210\211\212\222\223\224\225\226\227\230\231\232\242\243\244\245\246\247\250\251\252\262\263\264\265\266\267\270\271\272\302\303\304\305\306\307\310\311\312\322\323\324\325\326\327\330\331\332\341\342\343\344\345\346\347\350\351\352\361\362\363\364\365\366\367\370\371\372\377\304\000\037\001\000\003"}}}

(gdb) p *(struct in6_addr *)sa
$3 = {__in6_u = {__u6_addr8 =
"\n\v\377\304\000\265\020\000\002\001\003\003\002\004\003\005",
__u6_addr16 = {2826, 50431, 46336,
  16, 258, 771, 1026, 1283}, __u6_addr32 = {3305048842, 1094912,
50528514, 84083714}}}


Stefan

Am 24.02.2017 um 14:18 schrieb Yann Ylavic:
> Hi Stefan (Priebe),
> 
> Is IPv6 (really) involved in your network?
> 
> Could you please show up the gdb output of the below ?
> 
> On Fri, Feb 24, 2017 at 2:07 PM, Yann Ylavic  wrote:
>>
>> 1078 APR_DECLARE(int) apr_ipsubnet_test(apr_ipsubnet_t *ipsub,
>> apr_sockaddr_t *sa)
>> 1079 {
>> 1080 #if APR_HAVE_IPV6
>> 1081 /* XXX This line will segv on Win32 build with APR_HAVE_IPV6,
>> 1082  * but without the IPV6 drivers installed.
>> 1083  */
>> 1084 if (sa->family == AF_INET) {
>> 1085 if (ipsub->family == AF_INET &&
>> 1086 ((sa->sa.sin.sin_addr.s_addr & ipsub->mask[0]) ==
>> ipsub->sub[0])) {
>> 1087 return 1;
>> 1088 }
>> 1089 }
>> 1090 else if (IN6_IS_ADDR_V4MAPPED((struct in6_addr *)sa->ipaddr_ptr)) {
>> 1091 if (ipsub->family == AF_INET &&
>> 1092 (((apr_uint32_t *)sa->ipaddr_ptr)[3] &
>> ipsub->mask[0]) == ipsub->sub[0]) {
>> 1093 return 1;
>> 1094 }
>> 1095 }
> 
> (gdb) p *ipsub
> (gdb) p *sa
> (gdb) p *(struct in6_addr *)sa
> 
> and possibly more to come...
> 
> 
> Thanks,
> Yann.
> 

Re: release v1.9.0

[Yann Ylavic]

On Fri, Feb 24, 2017 at 5:39 PM, Stefan Priebe - Profihost AG
 wrote:
> No we don't use IPv6 at all. Do you still need those values?

Yes please.

Regards,
Yann.

Re: release v1.9.0

[Stefan Priebe - Profihost AG]

No we don't use IPv6 at all. Do you still need those values?

Greets,
Stefan

Excuse my typo sent from my mobile phone.

> Am 24.02.2017 um 14:18 schrieb Yann Ylavic :
> 
> Hi Stefan (Priebe),
> 
> Is IPv6 (really) involved in your network?
> 
> Could you please show up the gdb output of the below ?
> 
>> On Fri, Feb 24, 2017 at 2:07 PM, Yann Ylavic  wrote:
>> 
>> 1078 APR_DECLARE(int) apr_ipsubnet_test(apr_ipsubnet_t *ipsub,
>> apr_sockaddr_t *sa)
>> 1079 {
>> 1080 #if APR_HAVE_IPV6
>> 1081 /* XXX This line will segv on Win32 build with APR_HAVE_IPV6,
>> 1082  * but without the IPV6 drivers installed.
>> 1083  */
>> 1084 if (sa->family == AF_INET) {
>> 1085 if (ipsub->family == AF_INET &&
>> 1086 ((sa->sa.sin.sin_addr.s_addr & ipsub->mask[0]) ==
>> ipsub->sub[0])) {
>> 1087 return 1;
>> 1088 }
>> 1089 }
>> 1090 else if (IN6_IS_ADDR_V4MAPPED((struct in6_addr *)sa->ipaddr_ptr)) {
>> 1091 if (ipsub->family == AF_INET &&
>> 1092 (((apr_uint32_t *)sa->ipaddr_ptr)[3] &
>> ipsub->mask[0]) == ipsub->sub[0]) {
>> 1093 return 1;
>> 1094 }
>> 1095 }
> 
> (gdb) p *ipsub
> (gdb) p *sa
> (gdb) p *(struct in6_addr *)sa
> 
> and possibly more to come...
> 
> 
> Thanks,
> Yann.

Re: release v1.9.0

[Yann Ylavic]

Hi Stefan (Priebe),

Is IPv6 (really) involved in your network?

Could you please show up the gdb output of the below ?

On Fri, Feb 24, 2017 at 2:07 PM, Yann Ylavic  wrote:
>
> 1078 APR_DECLARE(int) apr_ipsubnet_test(apr_ipsubnet_t *ipsub,
> apr_sockaddr_t *sa)
> 1079 {
> 1080 #if APR_HAVE_IPV6
> 1081 /* XXX This line will segv on Win32 build with APR_HAVE_IPV6,
> 1082  * but without the IPV6 drivers installed.
> 1083  */
> 1084 if (sa->family == AF_INET) {
> 1085 if (ipsub->family == AF_INET &&
> 1086 ((sa->sa.sin.sin_addr.s_addr & ipsub->mask[0]) ==
> ipsub->sub[0])) {
> 1087 return 1;
> 1088 }
> 1089 }
> 1090 else if (IN6_IS_ADDR_V4MAPPED((struct in6_addr *)sa->ipaddr_ptr)) {
> 1091 if (ipsub->family == AF_INET &&
> 1092 (((apr_uint32_t *)sa->ipaddr_ptr)[3] &
> ipsub->mask[0]) == ipsub->sub[0]) {
> 1093 return 1;
> 1094 }
> 1095 }

(gdb) p *ipsub
(gdb) p *sa
(gdb) p *(struct in6_addr *)sa

and possibly more to come...


Thanks,
Yann.

Re: release v1.9.0

[Yann Ylavic]

On Fri, Feb 24, 2017 at 1:35 PM, Stefan Eissing
 wrote:
> Meh.
>
> Stefan: once during the last 2 days or several?
>
>
> This is accessing r->useragent_addr by mod_access_compat which is, for h2 
> slaves, initialized with c->client_addr.
>
> Since c->client_addr is always initialized by the master connection, I did 
> not see any race issues with sharing this across multiple slaves. Anyone has 
> an idea?

No idea, but don't see it related to http2, though.

I'm there:

1078 APR_DECLARE(int) apr_ipsubnet_test(apr_ipsubnet_t *ipsub,
apr_sockaddr_t *sa)
1079 {
1080 #if APR_HAVE_IPV6
1081 /* XXX This line will segv on Win32 build with APR_HAVE_IPV6,
1082  * but without the IPV6 drivers installed.
1083  */
1084 if (sa->family == AF_INET) {
1085 if (ipsub->family == AF_INET &&
1086 ((sa->sa.sin.sin_addr.s_addr & ipsub->mask[0]) ==
ipsub->sub[0])) {
1087 return 1;
1088 }
1089 }
1090 else if (IN6_IS_ADDR_V4MAPPED((struct in6_addr *)sa->ipaddr_ptr)) {
1091 if (ipsub->family == AF_INET &&
1092 (((apr_uint32_t *)sa->ipaddr_ptr)[3] &
ipsub->mask[0]) == ipsub->sub[0]) {
1093 return 1;
1094 }
1095 }
1096 else if (sa->family == AF_INET6 && ipsub->family == AF_INET6) {
1097 apr_uint32_t *addr = (apr_uint32_t *)sa->ipaddr_ptr;
1098
1099 if ((addr[0] & ipsub->mask[0]) == ipsub->sub[0] &&
1100 (addr[1] & ipsub->mask[1]) == ipsub->sub[1] &&
1101 (addr[2] & ipsub->mask[2]) == ipsub->sub[2] &&
1102 (addr[3] & ipsub->mask[3]) == ipsub->sub[3]) {
1103 return 1;
1104 }
1105 }
1106 #else
1107 if ((sa->sa.sin.sin_addr.s_addr & ipsub->mask[0]) == ipsub->sub[0]) {
1108 return 1;
1109 }
1110 #endif /* APR_HAVE_IPV6 */
 return 0; /* no match */
1112 }

=> IN6_IS_ADDR_V4MAPPED((struct in6_addr *)sa->ipaddr_ptr)

Hmm...

Re: release v1.9.0

[Stefan Eissing]

Meh.

Stefan: once during the last 2 days or several?


This is accessing r->useragent_addr by mod_access_compat which is, for h2 
slaves, initialized with c->client_addr.

Since c->client_addr is always initialized by the master connection, I did not 
see any race issues with sharing this across multiple slaves. Anyone has an 
idea?

> Am 24.02.2017 um 12:33 schrieb Stefan Priebe - Profihost AG 
> :
> 
> Hi Yann,
>  Hi Stefan,
> 
> new trace:
> Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x7f459699740c in apr_ipsubnet_test (ipsub=0x7f44c003d070,
>sa=0x7f4570021950) at network_io/unix/sockaddr.c:1090
> #0  0x7f459699740c in apr_ipsubnet_test (ipsub=0x7f44c003d070,
>sa=0x7f4570021950) at network_io/unix/sockaddr.c:1090
> #1  0x7f459573b400 in find_allowdeny (r=r@entry=0x7f44c002c250,
>method=method@entry=0, a=, a=)
>at mod_access_compat.c:270
> #2  0x7f459573b59a in check_dir_access (r=0x7f44c002c250)
>at mod_access_compat.c:324
> #3  0x560ce8333fd0 in ap_run_access_checker (r=0x7f44c002c250)
>at request.c:87
> #4  0x560ce8336ea8 in ap_process_request_internal (r=0x7f44c002c250)
>at request.c:265
> #5  0x560ce8377b40 in ap_process_async_request (r=0x7f44c002c250)
>at http_request.c:434
> #6  0x560ce8377cf0 in ap_process_request (r=0x7f44c002c250)
>at http_request.c:471
> #7  0x560ce83b8aad in h2_task_process_request (c=,
>task=) at h2_task.c:612
> #8  h2_task_process_conn (c=0x7f44c003d070) at h2_task.c:659
> #9  0x560ce8347fd0 in ap_run_process_connection (c=0x7f44c0026220)
>at connection.c:42
> #10 0x560ce83b9eaf in h2_task_do (task=0x7f44c002a240,
>thread=0x560ce8afc900, worker_id=365015362) at h2_task.c:578
> #11 0x560ce83c362f in execute (thread=0x560ce8afc900,
> wctx=0x560ce8afc8c0)
>at h2_worker.c:46
> #12 0x7f45967610a4 in start_thread ()
>   from /lib/x86_64-linux-gnu/libpthread.so.0
> #13 0x7f459649662d in clone () from /lib/x86_64-linux-gnu/libc.so.6
> 
> Stefan
> 
> Am 23.02.2017 um 07:59 schrieb Stefan Priebe - Profihost AG:
>> Am 22.02.2017 um 12:22 schrieb Yann Ylavic:
>>> Hi Stefan,
>>> 
>>> On Wed, Feb 22, 2017 at 11:32 AM, Stefan Priebe - Profihost AG
>>>  wrote:
 
 @Yann how should i test? Vanilla 2.4.25 + MPM V7 + mod_http2 v1.9.1?
>>> 
>>> Yes, I think this is the right thing to do for now (no more patches than 
>>> v7).
>>> 
 Or
 do i need V8 or something else?
>>> 
>>> Not ready yet, I'll propose it when that's the case if you can test it then.
>>> That's an mpm_event optimization (hopefully) only, v7 is good from
>>> correctness POV...
>> 
>> OK it's running. Will report back.
>> 
>> Greets,
>> Stefan
>> 
>>> Thanks for testing, still!
>>> 
>>> Regards,
>>> Yann.
>>> 

Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

Re: release v1.9.0

[Stefan Priebe - Profihost AG]

Hi Yann,
  Hi Stefan,

new trace:
Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f459699740c in apr_ipsubnet_test (ipsub=0x7f44c003d070,
sa=0x7f4570021950) at network_io/unix/sockaddr.c:1090
#0  0x7f459699740c in apr_ipsubnet_test (ipsub=0x7f44c003d070,
sa=0x7f4570021950) at network_io/unix/sockaddr.c:1090
#1  0x7f459573b400 in find_allowdeny (r=r@entry=0x7f44c002c250,
method=method@entry=0, a=, a=)
at mod_access_compat.c:270
#2  0x7f459573b59a in check_dir_access (r=0x7f44c002c250)
at mod_access_compat.c:324
#3  0x560ce8333fd0 in ap_run_access_checker (r=0x7f44c002c250)
at request.c:87
#4  0x560ce8336ea8 in ap_process_request_internal (r=0x7f44c002c250)
at request.c:265
#5  0x560ce8377b40 in ap_process_async_request (r=0x7f44c002c250)
at http_request.c:434
#6  0x560ce8377cf0 in ap_process_request (r=0x7f44c002c250)
at http_request.c:471
#7  0x560ce83b8aad in h2_task_process_request (c=,
task=) at h2_task.c:612
#8  h2_task_process_conn (c=0x7f44c003d070) at h2_task.c:659
#9  0x560ce8347fd0 in ap_run_process_connection (c=0x7f44c0026220)
at connection.c:42
#10 0x560ce83b9eaf in h2_task_do (task=0x7f44c002a240,
thread=0x560ce8afc900, worker_id=365015362) at h2_task.c:578
#11 0x560ce83c362f in execute (thread=0x560ce8afc900,
wctx=0x560ce8afc8c0)
at h2_worker.c:46
#12 0x7f45967610a4 in start_thread ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#13 0x7f459649662d in clone () from /lib/x86_64-linux-gnu/libc.so.6

Stefan

Am 23.02.2017 um 07:59 schrieb Stefan Priebe - Profihost AG:
> Am 22.02.2017 um 12:22 schrieb Yann Ylavic:
>> Hi Stefan,
>>
>> On Wed, Feb 22, 2017 at 11:32 AM, Stefan Priebe - Profihost AG
>>  wrote:
>>>
>>> @Yann how should i test? Vanilla 2.4.25 + MPM V7 + mod_http2 v1.9.1?
>>
>> Yes, I think this is the right thing to do for now (no more patches than v7).
>>
>>> Or
>>> do i need V8 or something else?
>>
>> Not ready yet, I'll propose it when that's the case if you can test it then.
>> That's an mpm_event optimization (hopefully) only, v7 is good from
>> correctness POV...
> 
> OK it's running. Will report back.
> 
> Greets,
> Stefan
> 
>> Thanks for testing, still!
>>
>> Regards,
>> Yann.
>>

Re: release v1.9.0

[Stefan Priebe - Profihost AG]

Am 22.02.2017 um 12:22 schrieb Yann Ylavic:
> Hi Stefan,
> 
> On Wed, Feb 22, 2017 at 11:32 AM, Stefan Priebe - Profihost AG
>  wrote:
>>
>> @Yann how should i test? Vanilla 2.4.25 + MPM V7 + mod_http2 v1.9.1?
> 
> Yes, I think this is the right thing to do for now (no more patches than v7).
> 
>> Or
>> do i need V8 or something else?
> 
> Not ready yet, I'll propose it when that's the case if you can test it then.
> That's an mpm_event optimization (hopefully) only, v7 is good from
> correctness POV...

OK it's running. Will report back.

Greets,
Stefan

> Thanks for testing, still!
> 
> Regards,
> Yann.
> 

Re: release v1.9.0

[Yann Ylavic]

Hi Stefan,

On Wed, Feb 22, 2017 at 11:32 AM, Stefan Priebe - Profihost AG
 wrote:
>
> @Yann how should i test? Vanilla 2.4.25 + MPM V7 + mod_http2 v1.9.1?

Yes, I think this is the right thing to do for now (no more patches than v7).

> Or
> do i need V8 or something else?

Not ready yet, I'll propose it when that's the case if you can test it then.
That's an mpm_event optimization (hopefully) only, v7 is good from
correctness POV...

Thanks for testing, still!

Regards,
Yann.

Re: release v1.9.0

[Stefan Priebe - Profihost AG]

Hi Stefan,
  Hi Yann,

thanks for v1.9.1 i'm happy to test.

@Yann how should i test? Vanilla 2.4.25 + MPM V7 + mod_http2 v1.9.1? Or
do i need V8 or something else?

Greets,
Stefan

Am 22.02.2017 um 11:31 schrieb Stefan Eissing:
> v1.9.1 is out. Please test at your leisure.
> 
>> Am 21.02.2017 um 09:40 schrieb Stefan Priebe - Profihost AG 
>> :
>>
>> Hi Yann,
>>
>> Am 20.02.2017 um 16:38 schrieb Yann Ylavic:
>>> On Wed, Feb 15, 2017 at 8:53 PM, Stefan Priebe - Profihost AG
>>>  wrote:

 still no segfaults.
>>>
>>> Great!
>>>

 @Yann
 Are those patches (the addon on top of v7) and the one on top of mod_ssl
 still correct / needed?
>>>
>>> I think so, but maybe I'm a bit lost (see below)...
>>>

 Am 15.02.2017 um 12:45 schrieb Stefan Priebe - Profihost AG:
>
> Am 15.02.2017 um 12:19 schrieb Yann Ylavic:
>>
>> Is this with or without the mpm_event's wakeup and/or allocator patches?
>
> it's with the mpm_event_listener_wakeup_bug57399_V7 +
>>>
>>> Does this includes any change besides v7 from bugzilla?
>>
>> Yes but just the ones mentioned below. I think i'll wait for v1.9.1 +
>> MPM v8 which may include your patch for mod_http2 as well? Stefan?
>>
>> Stefan
>>
>>>
>>> Also finally... I really wish we had something like v6 in mpm_event,
>>> these locks around pollset operations seem really unnecessary to me
>>> (and likely not good performance wise).
>>> I think the (very unlikely) race mentioned in
>>> https://svn.apache.org/r1779354 could be addressed in the listener
>>> itself (while processing the queues, lock held) rather than every
>>> worker.
>>>
>>> I you could try the v8 I'll try to propose soon it would be really
>>> nice of you (as usual ;)
>>>
>
> --- a/build/httpd/server/mpm/event/event.c  (revision 1776076)
> +++ b/build/httpd/server/mpm/event/event.c  (working copy)
>>>
>>> This one is needed I think, I was waiting for your feedbacks since it
>>> mainly affects http2.
>>> Everything looking good, I just committed it to trunk (r1783755), the
>>> final patch would be [1].
>>>
>>> I also committed the corresponding changes in mod_http2 (r1783756)
>>> which don't seem to be in v1.9.0, so you may need [2] and [3] too.
>>>
>
> Index: a/build/httpd/modules/ssl/ssl_engine_io.c
> ===
> --- a/build/httpd/modules/ssl/ssl_engine_io.c (revision 1781324)
> +++ b/build/httpd/modules/ssl/ssl_engine_io.c (working copy)
>>>
>>> This one is in trunk already (r1781582), but without this change:
>>>
> -if (APR_BUCKET_IS_METADATA(bucket)) {
> +if (APR_BUCKET_IS_METADATA(bucket) || !filter_ctx->pssl) {
>>>
>>> So I'd suggest to use [4] instead.
>>> No harm, though, this case cannot happen in current httpd, but as
>>> discussed in another thread we should handle it another way.
>>>
>>>
>>> To conclude, I think you should be using: httpd-2.4.25 +
>>> mod_http-v1.9.0 + PR57399-v7.patch + [1] + [2] + [3] + [4].
>>>
>>> Other than PR57399-v7, they are all in trunk now, so hopefully it will
>>> be easier to talk about them (e.g. with revision number).
>>>
>>> Regards,
>>> Yann.
>>>
>>>
>>> [1] 
>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/event/event.c?r1=1783755=1783754=1783755=patch
>>> (from r1783755)
>>> [2] 
>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_mplx.c?rev=1783756=1783755=1783756=diff
>>> (from r1783756)
>>> [3] 
>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_conn.c?rev=1783756=1783755=1783756=diff
>>> (from r1783756)
>>> [4] 
>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_io.c?r1=1781581=1781582=1781582=patch
>>> (from r1781582).
>>>
>>> PS: I could not find a way for viewvc URLs above to express a single
>>> diff for a whole revision change (e.g. [2] and [3] above are two files
>>> changed in the same commit...).
>>> With the svn client, it would be simply these three diffs:
>>> [svn.1] svn diff -r 1783754:1783755
>>> http://svn.apache.org/repos/asf/httpd/httpd/trunk/
>>> [svn.2-3] svn diff -r 1783755:1783756
>>> http://svn.apache.org/repos/asf/httpd/httpd/trunk/
>>> [svn.4] svn diff -r 1781581:1781582
>>> http://svn.apache.org/repos/asf/httpd/httpd/trunk/
> 
> Stefan Eissing
> 
> bytes GmbH
> Hafenstrasse 16
> 48155 Münster
> www.greenbytes.de
> 

Re: release v1.9.0

[Stefan Eissing]

v1.9.1 is out. Please test at your leisure.

> Am 21.02.2017 um 09:40 schrieb Stefan Priebe - Profihost AG 
> :
> 
> Hi Yann,
> 
> Am 20.02.2017 um 16:38 schrieb Yann Ylavic:
>> On Wed, Feb 15, 2017 at 8:53 PM, Stefan Priebe - Profihost AG
>>  wrote:
>>> 
>>> still no segfaults.
>> 
>> Great!
>> 
>>> 
>>> @Yann
>>> Are those patches (the addon on top of v7) and the one on top of mod_ssl
>>> still correct / needed?
>> 
>> I think so, but maybe I'm a bit lost (see below)...
>> 
>>> 
>>> Am 15.02.2017 um 12:45 schrieb Stefan Priebe - Profihost AG:
 
 Am 15.02.2017 um 12:19 schrieb Yann Ylavic:
> 
> Is this with or without the mpm_event's wakeup and/or allocator patches?
 
 it's with the mpm_event_listener_wakeup_bug57399_V7 +
>> 
>> Does this includes any change besides v7 from bugzilla?
> 
> Yes but just the ones mentioned below. I think i'll wait for v1.9.1 +
> MPM v8 which may include your patch for mod_http2 as well? Stefan?
> 
> Stefan
> 
>> 
>> Also finally... I really wish we had something like v6 in mpm_event,
>> these locks around pollset operations seem really unnecessary to me
>> (and likely not good performance wise).
>> I think the (very unlikely) race mentioned in
>> https://svn.apache.org/r1779354 could be addressed in the listener
>> itself (while processing the queues, lock held) rather than every
>> worker.
>> 
>> I you could try the v8 I'll try to propose soon it would be really
>> nice of you (as usual ;)
>> 
 
 --- a/build/httpd/server/mpm/event/event.c  (revision 1776076)
 +++ b/build/httpd/server/mpm/event/event.c  (working copy)
>> 
>> This one is needed I think, I was waiting for your feedbacks since it
>> mainly affects http2.
>> Everything looking good, I just committed it to trunk (r1783755), the
>> final patch would be [1].
>> 
>> I also committed the corresponding changes in mod_http2 (r1783756)
>> which don't seem to be in v1.9.0, so you may need [2] and [3] too.
>> 
 
 Index: a/build/httpd/modules/ssl/ssl_engine_io.c
 ===
 --- a/build/httpd/modules/ssl/ssl_engine_io.c (revision 1781324)
 +++ b/build/httpd/modules/ssl/ssl_engine_io.c (working copy)
>> 
>> This one is in trunk already (r1781582), but without this change:
>> 
 -if (APR_BUCKET_IS_METADATA(bucket)) {
 +if (APR_BUCKET_IS_METADATA(bucket) || !filter_ctx->pssl) {
>> 
>> So I'd suggest to use [4] instead.
>> No harm, though, this case cannot happen in current httpd, but as
>> discussed in another thread we should handle it another way.
>> 
>> 
>> To conclude, I think you should be using: httpd-2.4.25 +
>> mod_http-v1.9.0 + PR57399-v7.patch + [1] + [2] + [3] + [4].
>> 
>> Other than PR57399-v7, they are all in trunk now, so hopefully it will
>> be easier to talk about them (e.g. with revision number).
>> 
>> Regards,
>> Yann.
>> 
>> 
>> [1] 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/event/event.c?r1=1783755=1783754=1783755=patch
>> (from r1783755)
>> [2] 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_mplx.c?rev=1783756=1783755=1783756=diff
>> (from r1783756)
>> [3] 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_conn.c?rev=1783756=1783755=1783756=diff
>> (from r1783756)
>> [4] 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_io.c?r1=1781581=1781582=1781582=patch
>> (from r1781582).
>> 
>> PS: I could not find a way for viewvc URLs above to express a single
>> diff for a whole revision change (e.g. [2] and [3] above are two files
>> changed in the same commit...).
>> With the svn client, it would be simply these three diffs:
>> [svn.1] svn diff -r 1783754:1783755
>> http://svn.apache.org/repos/asf/httpd/httpd/trunk/
>> [svn.2-3] svn diff -r 1783755:1783756
>> http://svn.apache.org/repos/asf/httpd/httpd/trunk/
>> [svn.4] svn diff -r 1781581:1781582
>> http://svn.apache.org/repos/asf/httpd/httpd/trunk/

Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

Re: release v1.9.0

[Stefan Eissing]

Expect a v1.9.1 sometime this week.

> Am 21.02.2017 um 09:40 schrieb Stefan Priebe - Profihost AG 
> :
> 
> Hi Yann,
> 
> Am 20.02.2017 um 16:38 schrieb Yann Ylavic:
>> On Wed, Feb 15, 2017 at 8:53 PM, Stefan Priebe - Profihost AG
>>  wrote:
>>> 
>>> still no segfaults.
>> 
>> Great!
>> 
>>> 
>>> @Yann
>>> Are those patches (the addon on top of v7) and the one on top of mod_ssl
>>> still correct / needed?
>> 
>> I think so, but maybe I'm a bit lost (see below)...
>> 
>>> 
>>> Am 15.02.2017 um 12:45 schrieb Stefan Priebe - Profihost AG:
 
 Am 15.02.2017 um 12:19 schrieb Yann Ylavic:
> 
> Is this with or without the mpm_event's wakeup and/or allocator patches?
 
 it's with the mpm_event_listener_wakeup_bug57399_V7 +
>> 
>> Does this includes any change besides v7 from bugzilla?
> 
> Yes but just the ones mentioned below. I think i'll wait for v1.9.1 +
> MPM v8 which may include your patch for mod_http2 as well? Stefan?
> 
> Stefan
> 
>> 
>> Also finally... I really wish we had something like v6 in mpm_event,
>> these locks around pollset operations seem really unnecessary to me
>> (and likely not good performance wise).
>> I think the (very unlikely) race mentioned in
>> https://svn.apache.org/r1779354 could be addressed in the listener
>> itself (while processing the queues, lock held) rather than every
>> worker.
>> 
>> I you could try the v8 I'll try to propose soon it would be really
>> nice of you (as usual ;)
>> 
 
 --- a/build/httpd/server/mpm/event/event.c  (revision 1776076)
 +++ b/build/httpd/server/mpm/event/event.c  (working copy)
>> 
>> This one is needed I think, I was waiting for your feedbacks since it
>> mainly affects http2.
>> Everything looking good, I just committed it to trunk (r1783755), the
>> final patch would be [1].
>> 
>> I also committed the corresponding changes in mod_http2 (r1783756)
>> which don't seem to be in v1.9.0, so you may need [2] and [3] too.
>> 
 
 Index: a/build/httpd/modules/ssl/ssl_engine_io.c
 ===
 --- a/build/httpd/modules/ssl/ssl_engine_io.c (revision 1781324)
 +++ b/build/httpd/modules/ssl/ssl_engine_io.c (working copy)
>> 
>> This one is in trunk already (r1781582), but without this change:
>> 
 -if (APR_BUCKET_IS_METADATA(bucket)) {
 +if (APR_BUCKET_IS_METADATA(bucket) || !filter_ctx->pssl) {
>> 
>> So I'd suggest to use [4] instead.
>> No harm, though, this case cannot happen in current httpd, but as
>> discussed in another thread we should handle it another way.
>> 
>> 
>> To conclude, I think you should be using: httpd-2.4.25 +
>> mod_http-v1.9.0 + PR57399-v7.patch + [1] + [2] + [3] + [4].
>> 
>> Other than PR57399-v7, they are all in trunk now, so hopefully it will
>> be easier to talk about them (e.g. with revision number).
>> 
>> Regards,
>> Yann.
>> 
>> 
>> [1] 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/event/event.c?r1=1783755=1783754=1783755=patch
>> (from r1783755)
>> [2] 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_mplx.c?rev=1783756=1783755=1783756=diff
>> (from r1783756)
>> [3] 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_conn.c?rev=1783756=1783755=1783756=diff
>> (from r1783756)
>> [4] 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_io.c?r1=1781581=1781582=1781582=patch
>> (from r1781582).
>> 
>> PS: I could not find a way for viewvc URLs above to express a single
>> diff for a whole revision change (e.g. [2] and [3] above are two files
>> changed in the same commit...).
>> With the svn client, it would be simply these three diffs:
>> [svn.1] svn diff -r 1783754:1783755
>> http://svn.apache.org/repos/asf/httpd/httpd/trunk/
>> [svn.2-3] svn diff -r 1783755:1783756
>> http://svn.apache.org/repos/asf/httpd/httpd/trunk/
>> [svn.4] svn diff -r 1781581:1781582
>> http://svn.apache.org/repos/asf/httpd/httpd/trunk/
>> 

Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

Re: release v1.9.0

[Yann Ylavic]

On Wed, Feb 15, 2017 at 8:53 PM, Stefan Priebe - Profihost AG
 wrote:
>
> still no segfaults.

Great!

>
> @Yann
> Are those patches (the addon on top of v7) and the one on top of mod_ssl
> still correct / needed?

I think so, but maybe I'm a bit lost (see below)...

>
> Am 15.02.2017 um 12:45 schrieb Stefan Priebe - Profihost AG:
>>
>> Am 15.02.2017 um 12:19 schrieb Yann Ylavic:
>>>
>>> Is this with or without the mpm_event's wakeup and/or allocator patches?
>>
>> it's with the mpm_event_listener_wakeup_bug57399_V7 +

Does this includes any change besides v7 from bugzilla?

Also finally... I really wish we had something like v6 in mpm_event,
these locks around pollset operations seem really unnecessary to me
(and likely not good performance wise).
I think the (very unlikely) race mentioned in
https://svn.apache.org/r1779354 could be addressed in the listener
itself (while processing the queues, lock held) rather than every
worker.

I you could try the v8 I'll try to propose soon it would be really
nice of you (as usual ;)

>>
>> --- a/build/httpd/server/mpm/event/event.c  (revision 1776076)
>> +++ b/build/httpd/server/mpm/event/event.c  (working copy)

This one is needed I think, I was waiting for your feedbacks since it
mainly affects http2.
Everything looking good, I just committed it to trunk (r1783755), the
final patch would be [1].

I also committed the corresponding changes in mod_http2 (r1783756)
which don't seem to be in v1.9.0, so you may need [2] and [3] too.

>>
>> Index: a/build/httpd/modules/ssl/ssl_engine_io.c
>> ===
>> --- a/build/httpd/modules/ssl/ssl_engine_io.c (revision 1781324)
>> +++ b/build/httpd/modules/ssl/ssl_engine_io.c (working copy)

This one is in trunk already (r1781582), but without this change:

>> -if (APR_BUCKET_IS_METADATA(bucket)) {
>> +if (APR_BUCKET_IS_METADATA(bucket) || !filter_ctx->pssl) {

So I'd suggest to use [4] instead.
No harm, though, this case cannot happen in current httpd, but as
discussed in another thread we should handle it another way.


To conclude, I think you should be using: httpd-2.4.25 +
mod_http-v1.9.0 + PR57399-v7.patch + [1] + [2] + [3] + [4].

Other than PR57399-v7, they are all in trunk now, so hopefully it will
be easier to talk about them (e.g. with revision number).

Regards,
Yann.


[1] 
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/event/event.c?r1=1783755=1783754=1783755=patch
(from r1783755)
[2] 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_mplx.c?rev=1783756=1783755=1783756=diff
(from r1783756)
[3] 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_conn.c?rev=1783756=1783755=1783756=diff
(from r1783756)
[4] 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_io.c?r1=1781581=1781582=1781582=patch
(from r1781582).

PS: I could not find a way for viewvc URLs above to express a single
diff for a whole revision change (e.g. [2] and [3] above are two files
changed in the same commit...).
With the svn client, it would be simply these three diffs:
[svn.1] svn diff -r 1783754:1783755
http://svn.apache.org/repos/asf/httpd/httpd/trunk/
[svn.2-3] svn diff -r 1783755:1783756
http://svn.apache.org/repos/asf/httpd/httpd/trunk/
[svn.4] svn diff -r 1781581:1781582
http://svn.apache.org/repos/asf/httpd/httpd/trunk/

Re: release v1.9.0

[Eric Covener]

On Thu, Feb 16, 2017 at 2:16 PM, Stefan Eissing
 wrote:
> I will sleep soundly then. Thanks a lot! :)


Thanks to both of you for your persistence!

-- 
Eric Covener
cove...@gmail.com

Re: release v1.9.0

[Stefan Eissing]

> Am 16.02.2017 um 19:51 schrieb Stefan Priebe - Profihost AG 
> :
> 
> Hi,
> 
> Am 16.02.2017 um 11:39 schrieb Stefan Eissing:
>> 
>>> Am 15.02.2017 um 20:53 schrieb Stefan Priebe - Profihost AG 
>>> :
>>> 
>>> Hi,
>>> 
>>> still no segfaults.
>> 
>> My heart sings with joy. Can you keep on sending that message every morning? 
>> thanks!
> 
> I've no time tomorrow morning - so i've just checked again. Still no
> segfaults.

I will sleep soundly then. Thanks a lot! :)

>>> @Yann
>>> Are those patches (the addon on top of v7) and the one on top of mod_ssl
>>> still correct / needed?
>>> 
>>> Stefan
>>> 
>>> Am 15.02.2017 um 12:45 schrieb Stefan Priebe - Profihost AG:
 Hi,
 Am 15.02.2017 um 12:19 schrieb Yann Ylavic:
> Hi Stefan,
> 
> On Wed, Feb 15, 2017 at 9:34 AM, Stefan Priebe - Profihost AG
>  wrote:
>> Current status: no segfaults.
> 
> Is this with or without the mpm_event's wakeup and/or allocator patches?
 
 it's with the mpm_event_listener_wakeup_bug57399_V7 +
 
 --- a/build/httpd/server/mpm/event/event.c  (revision 1776076)
 +++ b/build/httpd/server/mpm/event/event.c  (working copy)
 @@ -1743,6 +1743,8 @@ static void * APR_THREAD_FUNC listener_thread(apr_
enable_listensocks(process_slot);
}
if (!listeners_disabled) {
 +apr_thread_mutex_t *mutex;
 +
lr = (ap_listen_rec *) pt->baton;
ap_pop_pool(, worker_queue_info);
 
 @@ -1751,19 +1753,24 @@ static void * APR_THREAD_FUNC listener_thread(apr_
apr_allocator_t *allocator;
 
apr_allocator_create();
 -apr_allocator_max_free_set(allocator,
 -   ap_max_mem_free);
 -apr_pool_create_ex(, pconf, NULL,
 allocator);
 -apr_allocator_owner_set(allocator, ptrans);
 -if (ptrans == NULL) {
 +apr_allocator_max_free_set(allocator,
 ap_max_mem_free);
 +rc = apr_pool_create_ex(, pconf, NULL,
 +allocator);
 +if (rc != APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_CRIT, rc,
 ap_server_conf, APLOGNO(03097)
 "Failed to create transaction
 pool");
 +apr_allocator_destroy(allocator);
signal_threads(ST_GRACEFUL);
return NULL;
}
 +apr_allocator_owner_set(allocator, ptrans);
 +apr_pool_tag(ptrans, "transaction");
}
 -apr_pool_tag(ptrans, "transaction");
 +apr_thread_mutex_create(,
 APR_THREAD_MUTEX_DEFAULT,
 +ptrans);
 +
 apr_allocator_mutex_set(apr_pool_allocator_get(ptrans),
 +mutex);
 
get_worker(_idle_worker, 1, _were_busy);
rc = lr->accept_func(, lr, ptrans);
 
 
 +
 
 Index: a/build/httpd/modules/ssl/ssl_engine_io.c
 ===
 --- a/build/httpd/modules/ssl/ssl_engine_io.c (revision 1781324)
 +++ b/build/httpd/modules/ssl/ssl_engine_io.c (working copy)
 @@ -138,6 +138,7 @@ static int bio_filter_out_pass(bio_filter_out_ctx_
 
outctx->rc = ap_pass_brigade(outctx->filter_ctx->pOutputFilter->next,
 outctx->bb);
 +apr_brigade_cleanup(outctx->bb);
/* Fail if the connection was reset: */
if (outctx->rc == APR_SUCCESS && outctx->c->aborted) {
outctx->rc = APR_ECONNRESET;
 @@ -1699,13 +1700,12 @@ static apr_status_t ssl_io_filter_output(ap_filter
while (!APR_BRIGADE_EMPTY(bb) && status == APR_SUCCESS) {
apr_bucket *bucket = APR_BRIGADE_FIRST(bb);
 
 -if (APR_BUCKET_IS_METADATA(bucket)) {
 +if (APR_BUCKET_IS_METADATA(bucket) || !filter_ctx->pssl) {
/* Pass through metadata buckets untouched.  EOC is
 * special; terminate the SSL layer first. */
if (AP_BUCKET_IS_EOC(bucket)) {
ssl_filter_io_shutdown(filter_ctx, f->c, 0);
}
 -AP_DEBUG_ASSERT(APR_BRIGADE_EMPTY(outctx->bb));
 
/* Metadata buckets are passed one per brigade; it might
 * be 

Re: release v1.9.0

[Stefan Priebe - Profihost AG]

Hi,

Am 16.02.2017 um 11:39 schrieb Stefan Eissing:
> 
>> Am 15.02.2017 um 20:53 schrieb Stefan Priebe - Profihost AG 
>> :
>>
>> Hi,
>>
>> still no segfaults.
> 
> My heart sings with joy. Can you keep on sending that message every morning? 
> thanks!

I've no time tomorrow morning - so i've just checked again. Still no
segfaults.

Greets,
Stefan

>> @Yann
>> Are those patches (the addon on top of v7) and the one on top of mod_ssl
>> still correct / needed?
>>
>> Stefan
>>
>> Am 15.02.2017 um 12:45 schrieb Stefan Priebe - Profihost AG:
>>> Hi,
>>> Am 15.02.2017 um 12:19 schrieb Yann Ylavic:
 Hi Stefan,

 On Wed, Feb 15, 2017 at 9:34 AM, Stefan Priebe - Profihost AG
  wrote:
> Current status: no segfaults.

 Is this with or without the mpm_event's wakeup and/or allocator patches?
>>>
>>> it's with the mpm_event_listener_wakeup_bug57399_V7 +
>>>
>>> --- a/build/httpd/server/mpm/event/event.c  (revision 1776076)
>>> +++ b/build/httpd/server/mpm/event/event.c  (working copy)
>>> @@ -1743,6 +1743,8 @@ static void * APR_THREAD_FUNC listener_thread(apr_
>>> enable_listensocks(process_slot);
>>> }
>>> if (!listeners_disabled) {
>>> +apr_thread_mutex_t *mutex;
>>> +
>>> lr = (ap_listen_rec *) pt->baton;
>>> ap_pop_pool(, worker_queue_info);
>>>
>>> @@ -1751,19 +1753,24 @@ static void * APR_THREAD_FUNC listener_thread(apr_
>>> apr_allocator_t *allocator;
>>>
>>> apr_allocator_create();
>>> -apr_allocator_max_free_set(allocator,
>>> -   ap_max_mem_free);
>>> -apr_pool_create_ex(, pconf, NULL,
>>> allocator);
>>> -apr_allocator_owner_set(allocator, ptrans);
>>> -if (ptrans == NULL) {
>>> +apr_allocator_max_free_set(allocator,
>>> ap_max_mem_free);
>>> +rc = apr_pool_create_ex(, pconf, NULL,
>>> +allocator);
>>> +if (rc != APR_SUCCESS) {
>>> ap_log_error(APLOG_MARK, APLOG_CRIT, rc,
>>>  ap_server_conf, APLOGNO(03097)
>>>  "Failed to create transaction
>>> pool");
>>> +apr_allocator_destroy(allocator);
>>> signal_threads(ST_GRACEFUL);
>>> return NULL;
>>> }
>>> +apr_allocator_owner_set(allocator, ptrans);
>>> +apr_pool_tag(ptrans, "transaction");
>>> }
>>> -apr_pool_tag(ptrans, "transaction");
>>> +apr_thread_mutex_create(,
>>> APR_THREAD_MUTEX_DEFAULT,
>>> +ptrans);
>>> +apr_allocator_mutex_set(apr_pool_allocator_get(ptrans),
>>> +mutex);
>>>
>>> get_worker(_idle_worker, 1, _were_busy);
>>> rc = lr->accept_func(, lr, ptrans);
>>>
>>>
>>> +
>>>
>>> Index: a/build/httpd/modules/ssl/ssl_engine_io.c
>>> ===
>>> --- a/build/httpd/modules/ssl/ssl_engine_io.c (revision 1781324)
>>> +++ b/build/httpd/modules/ssl/ssl_engine_io.c (working copy)
>>> @@ -138,6 +138,7 @@ static int bio_filter_out_pass(bio_filter_out_ctx_
>>>
>>> outctx->rc = ap_pass_brigade(outctx->filter_ctx->pOutputFilter->next,
>>>  outctx->bb);
>>> +apr_brigade_cleanup(outctx->bb);
>>> /* Fail if the connection was reset: */
>>> if (outctx->rc == APR_SUCCESS && outctx->c->aborted) {
>>> outctx->rc = APR_ECONNRESET;
>>> @@ -1699,13 +1700,12 @@ static apr_status_t ssl_io_filter_output(ap_filter
>>> while (!APR_BRIGADE_EMPTY(bb) && status == APR_SUCCESS) {
>>> apr_bucket *bucket = APR_BRIGADE_FIRST(bb);
>>>
>>> -if (APR_BUCKET_IS_METADATA(bucket)) {
>>> +if (APR_BUCKET_IS_METADATA(bucket) || !filter_ctx->pssl) {
>>> /* Pass through metadata buckets untouched.  EOC is
>>>  * special; terminate the SSL layer first. */
>>> if (AP_BUCKET_IS_EOC(bucket)) {
>>> ssl_filter_io_shutdown(filter_ctx, f->c, 0);
>>> }
>>> -AP_DEBUG_ASSERT(APR_BRIGADE_EMPTY(outctx->bb));
>>>
>>> /* Metadata buckets are passed one per brigade; it might
>>>  * be more efficient (but also more complex) to use
>>> @@ -1712,11 +1712,10 @@ static apr_status_t ssl_io_filter_output(ap_filter
>>>  * outctx->bb as a true buffer and interleave these with
>>>  * data buckets. */

Re: release v1.9.0

[Stefan Eissing]

> Am 15.02.2017 um 20:53 schrieb Stefan Priebe - Profihost AG 
> :
> 
> Hi,
> 
> still no segfaults.

My heart sings with joy. Can you keep on sending that message every morning? 
thanks!

> 
> @Yann
> Are those patches (the addon on top of v7) and the one on top of mod_ssl
> still correct / needed?
> 
> Stefan
> 
> Am 15.02.2017 um 12:45 schrieb Stefan Priebe - Profihost AG:
>> Hi,
>> Am 15.02.2017 um 12:19 schrieb Yann Ylavic:
>>> Hi Stefan,
>>> 
>>> On Wed, Feb 15, 2017 at 9:34 AM, Stefan Priebe - Profihost AG
>>>  wrote:
 Current status: no segfaults.
>>> 
>>> Is this with or without the mpm_event's wakeup and/or allocator patches?
>> 
>> it's with the mpm_event_listener_wakeup_bug57399_V7 +
>> 
>> --- a/build/httpd/server/mpm/event/event.c  (revision 1776076)
>> +++ b/build/httpd/server/mpm/event/event.c  (working copy)
>> @@ -1743,6 +1743,8 @@ static void * APR_THREAD_FUNC listener_thread(apr_
>> enable_listensocks(process_slot);
>> }
>> if (!listeners_disabled) {
>> +apr_thread_mutex_t *mutex;
>> +
>> lr = (ap_listen_rec *) pt->baton;
>> ap_pop_pool(, worker_queue_info);
>> 
>> @@ -1751,19 +1753,24 @@ static void * APR_THREAD_FUNC listener_thread(apr_
>> apr_allocator_t *allocator;
>> 
>> apr_allocator_create();
>> -apr_allocator_max_free_set(allocator,
>> -   ap_max_mem_free);
>> -apr_pool_create_ex(, pconf, NULL,
>> allocator);
>> -apr_allocator_owner_set(allocator, ptrans);
>> -if (ptrans == NULL) {
>> +apr_allocator_max_free_set(allocator,
>> ap_max_mem_free);
>> +rc = apr_pool_create_ex(, pconf, NULL,
>> +allocator);
>> +if (rc != APR_SUCCESS) {
>> ap_log_error(APLOG_MARK, APLOG_CRIT, rc,
>>  ap_server_conf, APLOGNO(03097)
>>  "Failed to create transaction
>> pool");
>> +apr_allocator_destroy(allocator);
>> signal_threads(ST_GRACEFUL);
>> return NULL;
>> }
>> +apr_allocator_owner_set(allocator, ptrans);
>> +apr_pool_tag(ptrans, "transaction");
>> }
>> -apr_pool_tag(ptrans, "transaction");
>> +apr_thread_mutex_create(,
>> APR_THREAD_MUTEX_DEFAULT,
>> +ptrans);
>> +apr_allocator_mutex_set(apr_pool_allocator_get(ptrans),
>> +mutex);
>> 
>> get_worker(_idle_worker, 1, _were_busy);
>> rc = lr->accept_func(, lr, ptrans);
>> 
>> 
>> +
>> 
>> Index: a/build/httpd/modules/ssl/ssl_engine_io.c
>> ===
>> --- a/build/httpd/modules/ssl/ssl_engine_io.c (revision 1781324)
>> +++ b/build/httpd/modules/ssl/ssl_engine_io.c (working copy)
>> @@ -138,6 +138,7 @@ static int bio_filter_out_pass(bio_filter_out_ctx_
>> 
>> outctx->rc = ap_pass_brigade(outctx->filter_ctx->pOutputFilter->next,
>>  outctx->bb);
>> +apr_brigade_cleanup(outctx->bb);
>> /* Fail if the connection was reset: */
>> if (outctx->rc == APR_SUCCESS && outctx->c->aborted) {
>> outctx->rc = APR_ECONNRESET;
>> @@ -1699,13 +1700,12 @@ static apr_status_t ssl_io_filter_output(ap_filter
>> while (!APR_BRIGADE_EMPTY(bb) && status == APR_SUCCESS) {
>> apr_bucket *bucket = APR_BRIGADE_FIRST(bb);
>> 
>> -if (APR_BUCKET_IS_METADATA(bucket)) {
>> +if (APR_BUCKET_IS_METADATA(bucket) || !filter_ctx->pssl) {
>> /* Pass through metadata buckets untouched.  EOC is
>>  * special; terminate the SSL layer first. */
>> if (AP_BUCKET_IS_EOC(bucket)) {
>> ssl_filter_io_shutdown(filter_ctx, f->c, 0);
>> }
>> -AP_DEBUG_ASSERT(APR_BRIGADE_EMPTY(outctx->bb));
>> 
>> /* Metadata buckets are passed one per brigade; it might
>>  * be more efficient (but also more complex) to use
>> @@ -1712,11 +1712,10 @@ static apr_status_t ssl_io_filter_output(ap_filter
>>  * outctx->bb as a true buffer and interleave these with
>>  * data buckets. */
>> APR_BUCKET_REMOVE(bucket);
>> -APR_BRIGADE_INSERT_HEAD(outctx->bb, bucket);
>> -status = ap_pass_brigade(f->next, outctx->bb);
>> -if (status == APR_SUCCESS && f->c->aborted)
>> -

Re: release v1.9.0

[Stefan Priebe - Profihost AG]

Hi,

still no segfaults.

@Yann
Are those patches (the addon on top of v7) and the one on top of mod_ssl
still correct / needed?

Stefan

Am 15.02.2017 um 12:45 schrieb Stefan Priebe - Profihost AG:
> Hi,
> Am 15.02.2017 um 12:19 schrieb Yann Ylavic:
>> Hi Stefan,
>>
>> On Wed, Feb 15, 2017 at 9:34 AM, Stefan Priebe - Profihost AG
>>  wrote:
>>> Current status: no segfaults.
>>
>> Is this with or without the mpm_event's wakeup and/or allocator patches?
> 
> it's with the mpm_event_listener_wakeup_bug57399_V7 +
> 
> --- a/build/httpd/server/mpm/event/event.c  (revision 1776076)
> +++ b/build/httpd/server/mpm/event/event.c  (working copy)
> @@ -1743,6 +1743,8 @@ static void * APR_THREAD_FUNC listener_thread(apr_
>  enable_listensocks(process_slot);
>  }
>  if (!listeners_disabled) {
> +apr_thread_mutex_t *mutex;
> +
>  lr = (ap_listen_rec *) pt->baton;
>  ap_pop_pool(, worker_queue_info);
> 
> @@ -1751,19 +1753,24 @@ static void * APR_THREAD_FUNC listener_thread(apr_
>  apr_allocator_t *allocator;
> 
>  apr_allocator_create();
> -apr_allocator_max_free_set(allocator,
> -   ap_max_mem_free);
> -apr_pool_create_ex(, pconf, NULL,
> allocator);
> -apr_allocator_owner_set(allocator, ptrans);
> -if (ptrans == NULL) {
> +apr_allocator_max_free_set(allocator,
> ap_max_mem_free);
> +rc = apr_pool_create_ex(, pconf, NULL,
> +allocator);
> +if (rc != APR_SUCCESS) {
>  ap_log_error(APLOG_MARK, APLOG_CRIT, rc,
>   ap_server_conf, APLOGNO(03097)
>   "Failed to create transaction
> pool");
> +apr_allocator_destroy(allocator);
>  signal_threads(ST_GRACEFUL);
>  return NULL;
>  }
> +apr_allocator_owner_set(allocator, ptrans);
> +apr_pool_tag(ptrans, "transaction");
>  }
> -apr_pool_tag(ptrans, "transaction");
> +apr_thread_mutex_create(,
> APR_THREAD_MUTEX_DEFAULT,
> +ptrans);
> +apr_allocator_mutex_set(apr_pool_allocator_get(ptrans),
> +mutex);
> 
>  get_worker(_idle_worker, 1, _were_busy);
>  rc = lr->accept_func(, lr, ptrans);
> 
> 
> +
> 
> Index: a/build/httpd/modules/ssl/ssl_engine_io.c
> ===
> --- a/build/httpd/modules/ssl/ssl_engine_io.c (revision 1781324)
> +++ b/build/httpd/modules/ssl/ssl_engine_io.c (working copy)
> @@ -138,6 +138,7 @@ static int bio_filter_out_pass(bio_filter_out_ctx_
> 
>  outctx->rc = ap_pass_brigade(outctx->filter_ctx->pOutputFilter->next,
>   outctx->bb);
> +apr_brigade_cleanup(outctx->bb);
>  /* Fail if the connection was reset: */
>  if (outctx->rc == APR_SUCCESS && outctx->c->aborted) {
>  outctx->rc = APR_ECONNRESET;
> @@ -1699,13 +1700,12 @@ static apr_status_t ssl_io_filter_output(ap_filter
>  while (!APR_BRIGADE_EMPTY(bb) && status == APR_SUCCESS) {
>  apr_bucket *bucket = APR_BRIGADE_FIRST(bb);
> 
> -if (APR_BUCKET_IS_METADATA(bucket)) {
> +if (APR_BUCKET_IS_METADATA(bucket) || !filter_ctx->pssl) {
>  /* Pass through metadata buckets untouched.  EOC is
>   * special; terminate the SSL layer first. */
>  if (AP_BUCKET_IS_EOC(bucket)) {
>  ssl_filter_io_shutdown(filter_ctx, f->c, 0);
>  }
> -AP_DEBUG_ASSERT(APR_BRIGADE_EMPTY(outctx->bb));
> 
>  /* Metadata buckets are passed one per brigade; it might
>   * be more efficient (but also more complex) to use
> @@ -1712,11 +1712,10 @@ static apr_status_t ssl_io_filter_output(ap_filter
>   * outctx->bb as a true buffer and interleave these with
>   * data buckets. */
>  APR_BUCKET_REMOVE(bucket);
> -APR_BRIGADE_INSERT_HEAD(outctx->bb, bucket);
> -status = ap_pass_brigade(f->next, outctx->bb);
> -if (status == APR_SUCCESS && f->c->aborted)
> -status = APR_ECONNRESET;
> -apr_brigade_cleanup(outctx->bb);
> +APR_BRIGADE_INSERT_TAIL(outctx->bb, bucket);
> +if (bio_filter_out_pass(outctx) < 0) {
> +status = outctx->rc;
> +}
>  }
>

Re: release v1.9.0

[Stefan Priebe - Profihost AG]

Hi,
Am 15.02.2017 um 12:19 schrieb Yann Ylavic:
> Hi Stefan,
> 
> On Wed, Feb 15, 2017 at 9:34 AM, Stefan Priebe - Profihost AG
>  wrote:
>> Current status: no segfaults.
> 
> Is this with or without the mpm_event's wakeup and/or allocator patches?

it's with the mpm_event_listener_wakeup_bug57399_V7 +

--- a/build/httpd/server/mpm/event/event.c  (revision 1776076)
+++ b/build/httpd/server/mpm/event/event.c  (working copy)
@@ -1743,6 +1743,8 @@ static void * APR_THREAD_FUNC listener_thread(apr_
 enable_listensocks(process_slot);
 }
 if (!listeners_disabled) {
+apr_thread_mutex_t *mutex;
+
 lr = (ap_listen_rec *) pt->baton;
 ap_pop_pool(, worker_queue_info);

@@ -1751,19 +1753,24 @@ static void * APR_THREAD_FUNC listener_thread(apr_
 apr_allocator_t *allocator;

 apr_allocator_create();
-apr_allocator_max_free_set(allocator,
-   ap_max_mem_free);
-apr_pool_create_ex(, pconf, NULL,
allocator);
-apr_allocator_owner_set(allocator, ptrans);
-if (ptrans == NULL) {
+apr_allocator_max_free_set(allocator,
ap_max_mem_free);
+rc = apr_pool_create_ex(, pconf, NULL,
+allocator);
+if (rc != APR_SUCCESS) {
 ap_log_error(APLOG_MARK, APLOG_CRIT, rc,
  ap_server_conf, APLOGNO(03097)
  "Failed to create transaction
pool");
+apr_allocator_destroy(allocator);
 signal_threads(ST_GRACEFUL);
 return NULL;
 }
+apr_allocator_owner_set(allocator, ptrans);
+apr_pool_tag(ptrans, "transaction");
 }
-apr_pool_tag(ptrans, "transaction");
+apr_thread_mutex_create(,
APR_THREAD_MUTEX_DEFAULT,
+ptrans);
+apr_allocator_mutex_set(apr_pool_allocator_get(ptrans),
+mutex);

 get_worker(_idle_worker, 1, _were_busy);
 rc = lr->accept_func(, lr, ptrans);


+

Index: a/build/httpd/modules/ssl/ssl_engine_io.c
===
--- a/build/httpd/modules/ssl/ssl_engine_io.c (revision 1781324)
+++ b/build/httpd/modules/ssl/ssl_engine_io.c (working copy)
@@ -138,6 +138,7 @@ static int bio_filter_out_pass(bio_filter_out_ctx_

 outctx->rc = ap_pass_brigade(outctx->filter_ctx->pOutputFilter->next,
  outctx->bb);
+apr_brigade_cleanup(outctx->bb);
 /* Fail if the connection was reset: */
 if (outctx->rc == APR_SUCCESS && outctx->c->aborted) {
 outctx->rc = APR_ECONNRESET;
@@ -1699,13 +1700,12 @@ static apr_status_t ssl_io_filter_output(ap_filter
 while (!APR_BRIGADE_EMPTY(bb) && status == APR_SUCCESS) {
 apr_bucket *bucket = APR_BRIGADE_FIRST(bb);

-if (APR_BUCKET_IS_METADATA(bucket)) {
+if (APR_BUCKET_IS_METADATA(bucket) || !filter_ctx->pssl) {
 /* Pass through metadata buckets untouched.  EOC is
  * special; terminate the SSL layer first. */
 if (AP_BUCKET_IS_EOC(bucket)) {
 ssl_filter_io_shutdown(filter_ctx, f->c, 0);
 }
-AP_DEBUG_ASSERT(APR_BRIGADE_EMPTY(outctx->bb));

 /* Metadata buckets are passed one per brigade; it might
  * be more efficient (but also more complex) to use
@@ -1712,11 +1712,10 @@ static apr_status_t ssl_io_filter_output(ap_filter
  * outctx->bb as a true buffer and interleave these with
  * data buckets. */
 APR_BUCKET_REMOVE(bucket);
-APR_BRIGADE_INSERT_HEAD(outctx->bb, bucket);
-status = ap_pass_brigade(f->next, outctx->bb);
-if (status == APR_SUCCESS && f->c->aborted)
-status = APR_ECONNRESET;
-apr_brigade_cleanup(outctx->bb);
+APR_BRIGADE_INSERT_TAIL(outctx->bb, bucket);
+if (bio_filter_out_pass(outctx) < 0) {
+status = outctx->rc;
+}
 }
 else {
 /* Filter a data bucket. */


Greets,
Stefan

Re: release v1.9.0

[Yann Ylavic]

Hi Stefan,

On Wed, Feb 15, 2017 at 9:34 AM, Stefan Priebe - Profihost AG
 wrote:
> Current status: no segfaults.

Is this with or without the mpm_event's wakeup and/or allocator patches?

Regards,
Yann.

Re: release v1.9.0

[Steffen]

Also here windows up and running on AL:

mod_http2 (v1.9.0-git, feats=, nghttp2 1.19.0), initializing...

Steffen


On Wednesday 15/02/2017 at 10:17, Stefan Eissing  wrote:

Thanks.



Am 15.02.2017 um 09:34 schrieb Stefan Priebe - Profihost AG 
:


Current status: no segfaults.



Am 14.02.2017 um 19:59 schrieb Stefan Priebe - Profihost AG:
Hi,

up and running - Thanks!

Greets,
Stefan



Am 14.02.2017 um 17:05 schrieb Stefan Eissing:
Stefan,

if you'd like, please throw
https://github.com/icing/mod_h2/releases/tag/v1.9.0
into your pit of segfaults and let's see if we find a new one!

Many thanks for testing.

Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
http://www.greenbytes.de

Re: release v1.9.0

[Stefan Eissing]

Thanks. 

> Am 15.02.2017 um 09:34 schrieb Stefan Priebe - Profihost AG 
> :
> 
> Current status: no segfaults.
> 
>> Am 14.02.2017 um 19:59 schrieb Stefan Priebe - Profihost AG:
>> Hi,
>> 
>> up and running - Thanks!
>> 
>> Greets,
>> Stefan
>> 
>>> Am 14.02.2017 um 17:05 schrieb Stefan Eissing:
>>> Stefan,
>>> 
>>> if you'd like, please throw
>>> https://github.com/icing/mod_h2/releases/tag/v1.9.0
>>> into your pit of segfaults and let's see if we find a new one!
>>> 
>>> Many thanks for testing.
>>> 
>>> Stefan Eissing
>>> 
>>> bytes GmbH
>>> Hafenstrasse 16
>>> 48155 Münster
>>> www.greenbytes.de
>>> 

Re: release v1.9.0

[Stefan Priebe - Profihost AG]

Current status: no segfaults.

Am 14.02.2017 um 19:59 schrieb Stefan Priebe - Profihost AG:
> Hi,
> 
> up and running - Thanks!
> 
> Greets,
> Stefan
> 
> Am 14.02.2017 um 17:05 schrieb Stefan Eissing:
>> Stefan,
>>
>> if you'd like, please throw
>> https://github.com/icing/mod_h2/releases/tag/v1.9.0
>> into your pit of segfaults and let's see if we find a new one!
>>
>> Many thanks for testing.
>>
>> Stefan Eissing
>>
>> bytes GmbH
>> Hafenstrasse 16
>> 48155 Münster
>> www.greenbytes.de
>>

Re: release v1.9.0

[Stefan Priebe - Profihost AG]

Hi,

up and running - Thanks!

Greets,
Stefan

Am 14.02.2017 um 17:05 schrieb Stefan Eissing:
> Stefan,
> 
> if you'd like, please throw
> https://github.com/icing/mod_h2/releases/tag/v1.9.0
> into your pit of segfaults and let's see if we find a new one!
> 
> Many thanks for testing.
> 
> Stefan Eissing
> 
> bytes GmbH
> Hafenstrasse 16
> 48155 Münster
> www.greenbytes.de
>