Hi Yann,
your last patch results in multiple crashes every second:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 apr_pool_cleanup_kill (p=0x7f2b00000000,
data=data@entry=0x7f2bb40478c0,
cleanup_fn=cleanup_fn@entry=0x7f2bc92285b0 <socket_cleanup>) at
memory/unix/apr_pools.c:2264
2264 memory/unix/apr_pools.c: No such file or directory.
#0 apr_pool_cleanup_kill (p=0x7f2b00000000,
data=data@entry=0x7f2bb40478c0,
cleanup_fn=cleanup_fn@entry=0x7f2bc92285b0 <socket_cleanup>) at
memory/unix/apr_pools.c:2264
#1 0x00007f2bc9224871 in apr_pool_cleanup_run (p=<optimized out>,
data=0x7f2bb40478c0, cleanup_fn=0x7f2bc92285b0 <socket_cleanup>)
at memory/unix/apr_pools.c:2342
#2 0x00007f2bc9228892 in apr_socket_close (thesocket=<optimized out>)
at network_io/unix/sockets.c:183
#3 0x0000555d4f07b99a in process_lingering_close (cs=0x7f2bb4047ac8,
pfd=0x555d4f75dfa8) at event.c:1510
#4 0x0000555d4f07f4e0 in listener_thread (thd=0x7f2b00000000,
dummy=0x547d8caf3534b) at event.c:1837
#5 0x00007f2bc8ff20a4 in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#6 0x00007f2bc8d2762d in clone () from /lib/x86_64-linux-gnu/libc.so.6
Stefan
Am 06.02.2017 um 09:33 schrieb Stefan Priebe - Profihost AG:
> 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
>> <s.pri...@profihost.ag> wrote:
>>>
>>> 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:
>>
>> Possibly a promising fix suggested (in another thread) by yet another
>> talented Stefan :)
>> He has spotted a possible issue in mpm_event which could affect mainly
>> mod_http2.
>> I applied his suggestion in the attached patch, and did some
>> extrapolation for similar code in mod_h2 (so all possible errors are
>> mine...).
>> Would you test this one please?
>>
>> @icing: I changed the parent pool of the slave connection from the
>> mplx pool to the master connection's (ptrans), just to simplify the
>> allocators in place for now.
>> I don't see it was needed from a concurrency POV, but if you wanted to
>> avoid locking when creating slaves' pool we can probably keep the
>> dedicated allocator finally (to reduce possible contention on
>> ptrans->mutex? No mutex needed I think since mplx doesn't seem to have
>> other subpools. Trade off with memory consumption, though).
>>
>>
>> Regards,
>> Yann.
>>
