Re: release v1.9.0
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,
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
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
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
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
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
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
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
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
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
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
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&r2=1783754&pathrev=1783755&view=patch
>>> (from r1783755)
>>> [2]
>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_mplx.c?rev=1783756&r1=1783755&r2=1783756&view=diff
>>> (from r1783756)
>>> [3]
>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_conn.c?rev=1783756&r1=1783755&r2=1783756&view=diff
>>> (from r1783756)
>>> [4]
>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_io.c?r1=1781581&r2=1781582&pathrev=1781582&view=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
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&r2=1783754&pathrev=1783755&view=patch
>> (from r1783755)
>> [2]
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_mplx.c?rev=1783756&r1=1783755&r2=1783756&view=diff
>> (from r1783756)
>> [3]
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_conn.c?rev=1783756&r1=1783755&r2=1783756&view=diff
>> (from r1783756)
>> [4]
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_io.c?r1=1781581&r2=1781582&pathrev=1781582&view=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
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&r2=1783754&pathrev=1783755&view=patch
>> (from r1783755)
>> [2]
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_mplx.c?rev=1783756&r1=1783755&r2=1783756&view=diff
>> (from r1783756)
>> [3]
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_conn.c?rev=1783756&r1=1783755&r2=1783756&view=diff
>> (from r1783756)
>> [4]
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_io.c?r1=1781581&r2=1781582&pathrev=1781582&view=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
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&r2=1783754&pathrev=1783755&view=patch
> (from r1783755)
> [2]
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_mplx.c?rev=1783756&r1=1783755&r2=1783756&view=diff
> (from r1783756)
> [3]
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_conn.c?rev=1783756&r1=1783755&r2=1783756&view=diff
> (from r1783756)
> [4]
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_io.c?r1=1781581&r2=1781582&pathrev=1781582&view=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
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&r2=1783754&pathrev=1783755&view=patch
(from r1783755)
[2]
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_mplx.c?rev=1783756&r1=1783755&r2=1783756&view=diff
(from r1783756)
[3]
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_conn.c?rev=1783756&r1=1783755&r2=1783756&view=diff
(from r1783756)
[4]
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_io.c?r1=1781581&r2=1781582&pathrev=1781582&view=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
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 [email protected]
Re: release v1.9.0
> 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(&ptrans, worker_queue_info);
@@ -1751,19 +1753,24 @@ static void * APR_THREAD_FUNC listener_thread(apr_
apr_allocator_t *allocator;
apr_allocator_create(&allocator);
-apr_allocator_max_free_set(allocator,
- ap_max_mem_free);
-apr_pool_create_ex(&ptrans, 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(&ptrans, 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(&mutex,
APR_THREAD_MUTEX_DEFAULT,
+ptrans);
+
apr_allocator_mutex_set(apr_pool_allocator_get(ptrans),
+mutex);
get_worker(&have_idle_worker, 1, &workers_were_busy);
rc = lr->accept_func(&csd, 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
Re: release v1.9.0
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(&ptrans, worker_queue_info);
>>>
>>> @@ -1751,19 +1753,24 @@ static void * APR_THREAD_FUNC listener_thread(apr_
>>> apr_allocator_t *allocator;
>>>
>>> apr_allocator_create(&allocator);
>>> -apr_allocator_max_free_set(allocator,
>>> - ap_max_mem_free);
>>> -apr_pool_create_ex(&ptrans, 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(&ptrans, 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(&mutex,
>>> APR_THREAD_MUTEX_DEFAULT,
>>> +ptrans);
>>> +apr_allocator_mutex_set(apr_pool_allocator_get(ptrans),
>>> +mutex);
>>>
>>> get_worker(&have_idle_worker, 1, &workers_were_busy);
>>> rc = lr->accept_func(&csd, 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 buck
Re: release v1.9.0
> 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(&ptrans, worker_queue_info);
>>
>> @@ -1751,19 +1753,24 @@ static void * APR_THREAD_FUNC listener_thread(apr_
>> apr_allocator_t *allocator;
>>
>> apr_allocator_create(&allocator);
>> -apr_allocator_max_free_set(allocator,
>> - ap_max_mem_free);
>> -apr_pool_create_ex(&ptrans, 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(&ptrans, 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(&mutex,
>> APR_THREAD_MUTEX_DEFAULT,
>> +ptrans);
>> +apr_allocator_mutex_set(apr_pool_allocator_get(ptrans),
>> +mutex);
>>
>> get_worker(&have_idle_worker, 1, &workers_were_busy);
>> rc = lr->accept_func(&csd, 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
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(&ptrans, worker_queue_info);
>
> @@ -1751,19 +1753,24 @@ static void * APR_THREAD_FUNC listener_thread(apr_
> apr_allocator_t *allocator;
>
> apr_allocator_create(&allocator);
> -apr_allocator_max_free_set(allocator,
> - ap_max_mem_free);
> -apr_pool_create_ex(&ptrans, 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(&ptrans, 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(&mutex,
> APR_THREAD_MUTEX_DEFAULT,
> +ptrans);
> +apr_allocator_mutex_set(apr_pool_allocator_get(ptrans),
> +mutex);
>
> get_worker(&have_idle_worker, 1, &workers_were_busy);
> rc = lr->accept_func(&csd, 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
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(&ptrans, worker_queue_info);
@@ -1751,19 +1753,24 @@ static void * APR_THREAD_FUNC listener_thread(apr_
apr_allocator_t *allocator;
apr_allocator_create(&allocator);
-apr_allocator_max_free_set(allocator,
- ap_max_mem_free);
-apr_pool_create_ex(&ptrans, 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(&ptrans, 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(&mutex,
APR_THREAD_MUTEX_DEFAULT,
+ptrans);
+apr_allocator_mutex_set(apr_pool_allocator_get(ptrans),
+mutex);
get_worker(&have_idle_worker, 1, &workers_were_busy);
rc = lr->accept_func(&csd, 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
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
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
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
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
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 >
