Hallo,
up and running (apache 2.4.25 + mpm_event V7 + mpd_http2 v1.8.11 +
mod_ssl patch + your new allocator patch). Will report back.
Greets,
Stefan
Am 06.02.2017 um 01:19 schrieb Yann Ylavic:
> Hi Stefan,
>
> On Sun, Feb 5, 2017 at 7:51 PM, Stefan Priebe - Profihost AG
> wrote:
>>
>> tested
Hi Yann,
your last patch results in multiple crashes every second:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 apr_pool_cleanup_kill (p=0x7f2b,
data=data@entry=0x7f2bb40478c0,
cleanup_fn=cleanup_fn@entry=0x7f2bc92285b0 ) at
memory/unix/apr_pools.c:2264
2264memor
ok, I'll look at them.
> Am 05.02.2017 um 19:51 schrieb Stefan Priebe - Profihost AG
> :
>
> Hi Yann,
>
> tested your patch against mod_ssl. I haven't seen any pool crashes again
> so it seems to fix this issue.
>
> But two new ones:
>
> Program terminated with signal SIGABRT, Aborted.
> #0
Thanks Yann (the one and only) for quickly adressing this. This explains maybe
some of my frustrations in the past with making pools/allocators work in the h2
environment.
-Stefan
> Am 06.02.2017 um 01:19 schrieb Yann Ylavic :
>
> Hi Stefan,
>
> On Sun, Feb 5, 2017 at 7:51 PM, Stefan Priebe
On 02-01-17 14:17, Thijs Kinkhorst wrote:
> I'd like to enquire about the possibilities to merge the patch to
> support configuring trusted OCSP responder certificates.
>
> We need this change in order to be able to use OCSP with client
> certificate authentication.
>
> The patch is in
> https://
Hi Stefan,
On Mon, Feb 6, 2017 at 9:57 AM, Stefan Priebe - Profihost AG
wrote:
>
> your last patch results in multiple crashes every second:
Sorry about that, the changes in mpm_event were incorrect (the mutex
was cleared with the pool when recycled, hence its pointer was
dangling).
New patch a
On Mon, Feb 6, 2017 at 11:28 AM, Thijs Kinkhorst
wrote:
> On 02-01-17 14:17, Thijs Kinkhorst wrote:
>> I'd like to enquire about the possibilities to merge the patch to
>> support configuring trusted OCSP responder certificates.
>>
>> We need this change in order to be able to use OCSP with client
On 02/02/2017 11:04 AM, Yann Ylavic wrote:
> Hi Niklas,
>
> On Wed, Feb 1, 2017 at 7:02 PM, Niklas Edmundsson wrote:
>>
>> We've started to see spurious segfaults with httpd 2.4.25, mpm_event, ssl on
>> Ubuntu 14.04LTS. Not frequent, but none the less happening.
>>
>> #4 ssl_io_filter_output (
On Mon, Feb 6, 2017 at 12:09 PM, Yann Ylavic wrote:
> On Mon, Feb 6, 2017 at 11:28 AM, Thijs Kinkhorst
> wrote:
>> On 02-01-17 14:17, Thijs Kinkhorst wrote:
>>> I'd like to enquire about the possibilities to merge the patch to
>>> support configuring trusted OCSP responder certificates.
>>>
>>> W
On Mon, Feb 6, 2017 at 12:10 PM, Ruediger Pluem wrote:
>>
>> What might happen in ssl_io_filter_output() is that buffered
>> output data (already deleted but not cleared) end up being reused
>> on shutdown.
>>
>> Could you please try the attached patch?
>
> Why would we need to handle filter_ctx->
> -Ursprüngliche Nachricht-
> Von: Yann Ylavic [mailto:ylavic@gmail.com]
> Gesendet: Freitag, 3. Februar 2017 18:06
> An: httpd-dev
> Betreff: ssl_io_filter_output vs EOC
>
> Besides metadata buckets, should the EOC semantic really apply to the
> ssl output filter?
>
> It's not rea
Am 06.02.2017 um 11:56 schrieb Yann Ylavic:
> Hi Stefan,
>
> On Mon, Feb 6, 2017 at 9:57 AM, Stefan Priebe - Profihost AG
> wrote:
>>
>> your last patch results in multiple crashes every second:
>
> Sorry about that, the changes in mpm_event were incorrect (the mutex
> was cleared with the pool
On 02/06/2017 11:56 AM, Yann Ylavic wrote:
> Hi Stefan,
>
> On Mon, Feb 6, 2017 at 9:57 AM, Stefan Priebe - Profihost AG
> wrote:
>>
>> your last patch results in multiple crashes every second:
>
> Sorry about that, the changes in mpm_event were incorrect (the mutex
> was cleared with the pool
On Mon, Feb 6, 2017 at 12:53 PM, Plüm, Rüdiger, Vodafone Group
wrote:
>
> IMHO we currently fail after we processed an EOC (no matter if in the
> same brigade or in a follow up brigade) and we should continue doing
> so.
We fail in the same brigade thanks to ssl_filter_write() when pssl is
NULL,
On Mon, Feb 6, 2017 at 1:29 PM, Ruediger Pluem wrote:
>
>
> On 02/06/2017 11:56 AM, Yann Ylavic wrote:
>> Hi Stefan,
>>
>> On Mon, Feb 6, 2017 at 9:57 AM, Stefan Priebe - Profihost AG
>> wrote:
>>>
>>> your last patch results in multiple crashes every second:
>>
>> Sorry about that, the changes i
On Mon, Feb 6, 2017 at 1:42 PM, Yann Ylavic wrote:
> On Mon, Feb 6, 2017 at 1:29 PM, Ruediger Pluem wrote:
>>
>>
>> On 02/06/2017 11:56 AM, Yann Ylavic wrote:
>>> Hi Stefan,
>>>
>>> On Mon, Feb 6, 2017 at 9:57 AM, Stefan Priebe - Profihost AG
>>> wrote:
your last patch results in multi
On 02/06/2017 01:31 PM, Yann Ylavic wrote:
> On Mon, Feb 6, 2017 at 12:53 PM, Plüm, Rüdiger, Vodafone Group
> wrote:
>>
>> IMHO we currently fail after we processed an EOC (no matter if in the
>> same brigade or in a follow up brigade) and we should continue doing
>> so.
>
> We fail in the same
On 02/06/2017 01:51 PM, Yann Ylavic wrote:
> On Mon, Feb 6, 2017 at 1:42 PM, Yann Ylavic wrote:
>> On Mon, Feb 6, 2017 at 1:29 PM, Ruediger Pluem wrote:
>>>
>>>
>>> On 02/06/2017 11:56 AM, Yann Ylavic wrote:
Hi Stefan,
On Mon, Feb 6, 2017 at 9:57 AM, Stefan Priebe - Profihost AG
Currently running some tests. Have crashes on the original patch in my test
suite. Fixed one, hunting for the next...
> Am 06.02.2017 um 14:23 schrieb Ruediger Pluem :
>
>
>
> On 02/06/2017 01:51 PM, Yann Ylavic wrote:
>> On Mon, Feb 6, 2017 at 1:42 PM, Yann Ylavic wrote:
>>> On Mon, Feb 6, 2
On Mon, Feb 6, 2017 at 2:31 PM, Stefan Eissing
wrote:
> Currently running some tests. Have crashes on the original patch in my test
> suite. Fixed one, hunting for the next...
I think it comes from my change that creates slave connections from
master->pool (instead of mplx's), because now slave'
On Mon, Feb 6, 2017 at 2:23 PM, Ruediger Pluem wrote:
>
> The question how much cycles this spends in GLIBC / kernel. I don't
> know. So maybe its not worth the effort. But if its not worth the
> effort it is worth documenting why :-)
Sure ;)
Yes, that was mixing the order. The attached v4 compiles and runs the h2 tests
for me without errors.
ptrans_and_slaves_allocator-v4.patch
Description: Binary data
> Am 06.02.2017 um 14:43 schrieb Yann Ylavic :
>
> On Mon, Feb 6, 2017 at 2:31 PM, Stefan Eissing
> wrote:
>> Currently running
Hi,
so i should test the mpm event part from Yann + your http2 part?
Stefan
Am 06.02.2017 um 15:34 schrieb Stefan Eissing:
> Yes, that was mixing the order. The attached v4 compiles and runs the h2
> tests for me without errors.
>
>
>
>
>
>> Am 06.02.2017 um 14:43 schrieb Yann Ylavic :
>>
On 06-02-17 12:09, Yann Ylavic wrote:
>> Is there anyone who can help me with this? Anything we can do?
> The patch was committed[1], and is being reviewed (possibly proposed
> for backport to 2.4.x soon).
Great news, I missed that recent change, thanks!
Cheers,
Thijs
signature.asc
Descriptio
I took Yann's v3 patch and changed a tiny bit in the h2. I just added a var
declaration in event.c without which it did not compile for me.
-Stefan
> Am 06.02.2017 um 15:41 schrieb Stefan Priebe - Profihost AG
> :
>
> Hi,
>
> so i should test the mpm event part from Yann + your http2 part?
>
Am 06.02.2017 um 16:03 schrieb Stefan Eissing:
> I took Yann's v3 patch and changed a tiny bit in the h2. I just added a var
> declaration in event.c without which it did not compile for me.
But your patch does not contain the changes to the event mpm. That's why
i ask.
Stefan
> -Stefan
>
>> A
It does, at the end. Traversed the directories in different order it seems.
> Am 06.02.2017 um 16:05 schrieb Stefan Priebe - Profihost AG
> :
>
> Am 06.02.2017 um 16:03 schrieb Stefan Eissing:
>> I took Yann's v3 patch and changed a tiny bit in the h2. I just added a var
>> declaration in event
Am 06.02.2017 um 16:06 schrieb Stefan Eissing:
> It does, at the end. Traversed the directories in different order it seems.
*arg* sorry
>
>> Am 06.02.2017 um 16:05 schrieb Stefan Priebe - Profihost AG
>> :
>>
>> Am 06.02.2017 um 16:03 schrieb Stefan Eissing:
>>> I took Yann's v3 patch and chang
On 02/03/2017 12:30 AM, Niklas Edmundsson wrote:
Methinks this makes mmap+ssl a VERY bad combination if the thing
SIGBUS:es due to a simple IO error, I'll proceed with disabling mmap and
see if that is a viable way to go for our workload...
(Pulling from a parallel conversation, with permission
On 02/05/2017 05:10 AM, Jim Jagielski wrote:
Not seeing anything fpm_main.c...
Line 1144 in my copy (attached). It's an example of an Apache-specific
fixup that only runs if apache_was_here is *false*.
--Jacob
if (!apache_was_here && env_path_translated != NULL && env_redirect_url !=
NU
On 02/04/2017 09:14 PM, drugg...@apache.org wrote:
> Author: druggeri
> Date: Sat Feb 4 20:14:18 2017
> New Revision: 1781701
>
> URL: http://svn.apache.org/viewvc?rev=1781701&view=rev
> Log:
> Change tactic for PROXY processing in Optional case
>
> Modified:
> httpd/httpd/trunk/docs/manua
Hi Stefan,
this one does not apply on top of yann's
mpm_event_listener_wakeup_bug57399_V7.patch patch.
Stefan
Am 06.02.2017 um 15:34 schrieb Stefan Eissing:
> Yes, that was mixing the order. The attached v4 compiles and runs the h2
> tests for me without errors.
>
>
>
>
>
>> Am 06.02.2017 u
Am 06.02.2017 um 22:22 schrieb Stefan Priebe - Profihost AG:
> Hi Stefan,
>
> this one does not apply on top of yann's
> mpm_event_listener_wakeup_bug57399_V7.patch patch.
i've now used his patch to mpm and yours for mod_http2.
Stefan
>
> Stefan
> Am 06.02.2017 um 15:34 schrieb Stefan Eissing:
Ok, thanks. I did not have the other one in place.
> Am 06.02.2017 um 22:24 schrieb Stefan Priebe - Profihost AG
> :
>
>> Am 06.02.2017 um 22:22 schrieb Stefan Priebe - Profihost AG:
>> Hi Stefan,
>>
>> this one does not apply on top of yann's
>> mpm_event_listener_wakeup_bug57399_V7.patch pat
34 matches
Mail list logo