Re: mod_http2 and Frequent wake-ups for mpm_event

Am 20.01.2017 um 08:20 schrieb Yann Ylavic: > Hi, > > On Fri, Jan 20, 2017 at 8:03 AM, Stefan Priebe - Profihost AG > wrote: >> Hi Stefan, >> >> Am 19.01.2017 um 22:44 schrieb Stefan Eissing: >>> this seems to be a tough bone to chew. Therefore we need to go deeper: >>> -

Re: mod_http2 and Frequent wake-ups for mpm_event

Hi, On Fri, Jan 20, 2017 at 8:03 AM, Stefan Priebe - Profihost AG wrote: > Hi Stefan, > > Am 19.01.2017 um 22:44 schrieb Stefan Eissing: >> this seems to be a tough bone to chew. Therefore we need to go deeper: >> - can you compile the module so that we see line numbers in

Re: mod_http2 and Frequent wake-ups for mpm_event

Hi Stefan, Am 19.01.2017 um 22:44 schrieb Stefan Eissing: > this seems to be a tough bone to chew. Therefore we need to go deeper: > - can you compile the module so that we see line numbers in the trace? Do you have any idea how to arrange this? I've no idea how to pass the -ggdb option through

Re: HTTP/2 frame prioritization not honored

* ... and by "here" I meant "here " On Thu, Jan 19, 2017 at 6:54 PM, Kyriakos Zarifis wrote: > Sounds great! > > >> Very interested. I'd like to add a page over at >>

Re: HTTP/2 frame prioritization not honored

Sounds great! > Very interested. I'd like to add a page over at > https://icing.github.io/mod_h2/ about it, so that people can easily grasp > what the advantages are. For that, your numbers (do you have screenshots of > browser timelines maybe?) would be very welcome. Also that someone besides >

Re: Alternate versioning proposal: patch line releases

On 20.01.2017, at 02:00, Eric Covener wrote: > > On Thu, Jan 19, 2017 at 6:49 PM, Jacob Champion wrote: >> We branch off from the 2.4.25 tag. This is our low-risk 2.4.25.x patch line. >> There are no new features or large code changes to this branch,

Re: Alternate versioning proposal: patch line releases

On Thu, Jan 19, 2017 at 6:49 PM, Jacob Champion wrote: > We branch off from the 2.4.25 tag. This is our low-risk 2.4.25.x patch line. > There are no new features or large code changes to this branch, there are no > refactorings or whitespace changes or huge cleanups; the

Re: Reset out x.minor.z definition of 'minor' at httpd?

On Thu, Jan 19, 2017 at 4:43 PM, William A Rowe Jr wrote: > I think one of our disconnects with 2.4 -> 2.6 is that in any other > framework, there would be no ABI breakage in 2.6. That breakage > would be deferred to and shipped as 3.0. > > The httpd project choose to call

Re: Alternate versioning proposal: patch line releases

On 01/19/2017 04:25 PM, Stefan Sperling wrote: On Thu, Jan 19, 2017 at 03:49:14PM -0800, Jacob Champion wrote: We branch off from the 2.4.25 tag. I am not sure you mean this literally, but anyway: I mean that the 2.4.25.x branch starts from the commit that we tagged as 2.4.25. That's all.

Re: Alternate versioning proposal: patch line releases

On Thu, Jan 19, 2017 at 03:49:14PM -0800, Jacob Champion wrote: > We branch off from the 2.4.25 tag. I am not sure you mean this literally, but anyway: While basing a branch off of a tag (svn copy ^/tags/foo ^/branches/newbranch) works, I would recommend to always create a branch first, and then

Re: Alternate versioning proposal: patch line releases

On 01/19/2017 03:57 PM, David Zuelke wrote: Please no .micro releases. Most of the world is now trying to stick to http://semver.org principles. I agree with you, actually, but as you know, httpd is not on SemVer currently and I'm not sure we can get there before 3.0. Maybe we'll all agree

Re: Reset out x.minor.z definition of 'minor' at httpd?

I don't know any framework/language/library out there that handles it that strictly. Nginx, or Ruby, or PHP, or whatever... From x.y.z to x.y.z+1, retain full compatibility. From x.y.z to x.y+1.0, keep external API compatibility, break ABI if needed, break internal API if absolutely needed

Re: Reset out x.minor.z definition of 'minor' at httpd?

Bill wrote: >I think one of our disconnects with 2.4 -> 2.6 is that in any other framework, >there would be > no ABI breakage in 2.6. That breakage would be deferred to and shipped as > 3.0. Huh? For just one single, simple example, what about APR?? Are we going to now redefine the

Re: Alternate versioning proposal: patch line releases

I can even imagine a world where that makes sense...

Re: Alternate versioning proposal: patch line releases

Please no .micro releases. Most of the world is now trying to stick to http://semver.org principles. Why not just keep 2.4 for maintenance, and start working on 2.6 immediately? Or 2.5? I honestly think that the current "odd numbers are unstable" approach is not helpful with this whole

Re: svn commit: r1779528 - /httpd/httpd/trunk/modules/http2/h2_mplx.c

On Thu, Jan 19, 2017 at 10:58 PM, Yann Ylavic wrote: > On Thu, Jan 19, 2017 at 10:41 PM, Stefan Eissing > wrote: >>> >>> We really need to not destroy m->pool in its parent's cleanup. >> >> Hmm, why is that bad? > > If the parent pool cleanup

Re: svn commit: r1779528 - /httpd/httpd/trunk/modules/http2/h2_mplx.c

Have to sleep over this. But I agree that this area needs some change. > Am 19.01.2017 um 23:31 schrieb Yann Ylavic : > > On Thu, Jan 19, 2017 at 10:58 PM, Yann Ylavic wrote: >> On Thu, Jan 19, 2017 at 10:41 PM, Stefan Eissing >>

Re: svn commit: r1779528 - /httpd/httpd/trunk/modules/http2/h2_mplx.c

On Thu, Jan 19, 2017 at 10:58 PM, Yann Ylavic wrote: > On Thu, Jan 19, 2017 at 10:41 PM, Stefan Eissing > wrote: >> >> Would work. But then we could just never destroy this directly, >> because it will always disappear via the parent h2_session

Re: Reset out x.minor.z definition of 'minor' at httpd?

On 01/19/2017 01:43 PM, William A Rowe Jr wrote: Once this is complete, binary breaking ABI changes would live in their own feature development forks. They would never be folded into trunk until there was a group consensus to push forward to version next.0.0 in the immediate future. trunk/ would

Re: Reset out x.minor.z definition of 'minor' at httpd?

Am 19.01.2017 um 22:43 schrieb William A Rowe Jr: I think one of our disconnects with 2.4 -> 2.6 is that in any other framework, there would be no ABI breakage in 2.6. That breakage would be deferred to and shipped as 3.0 every PHP version in the past decade (5.3, 5.4, 5.6, 7.0, 7.1, 7.2) is

Re: svn commit: r1779528 - /httpd/httpd/trunk/modules/http2/h2_mplx.c

On Thu, Jan 19, 2017 at 10:41 PM, Stefan Eissing wrote: >> >> We really need to not destroy m->pool in its parent's cleanup. > > Hmm, why is that bad? If the parent pool cleanup is called, that pool is being destroyed, which also destroys all its children pools (for

Re: [proposed] 2.4 Maintenance SIG

On 01/19/2017 12:52 PM, Noel Butler wrote: Frequent releases set off alarms in system admins minds, frequent releases give the view of unstable/unreliable software, and that is the largest cause of movement to an alternative. So, the last [1] two [2] times you've pushed this viewpoint, you've

Re: mod_http2 and Frequent wake-ups for mpm_event

Stefan, this seems to be a tough bone to chew. Therefore we need to go deeper: - can you compile the module so that we see line numbers in the trace? - which apr version are you using? - can you reproduce this at will? How? Which client? Just a GET or something more sophisticated? Thanks for

Reset out x.minor.z definition of 'minor' at httpd?

I think one of our disconnects with 2.4 -> 2.6 is that in any other framework, there would be no ABI breakage in 2.6. That breakage would be deferred to and shipped as 3.0. The httpd project choose to call 2.minor releases as breaking changes. Due to poor design choices, or frequent refactorings,

Re: svn commit: r1779528 - /httpd/httpd/trunk/modules/http2/h2_mplx.c

> Am 19.01.2017 um 22:38 schrieb Yann Ylavic : > > On Thu, Jan 19, 2017 at 10:09 PM, wrote: >> Author: icing >> Date: Thu Jan 19 21:09:18 2017 >> New Revision: 1779528 >> >> URL: http://svn.apache.org/viewvc?rev=1779528=rev >> Log: >> On the trunk: >>

Re: svn commit: r1779528 - /httpd/httpd/trunk/modules/http2/h2_mplx.c

On Thu, Jan 19, 2017 at 10:09 PM, wrote: > Author: icing > Date: Thu Jan 19 21:09:18 2017 > New Revision: 1779528 > > URL: http://svn.apache.org/viewvc?rev=1779528=rev > Log: > On the trunk: > > reverting change 1779525. We really need to not destroy m->pool in its parent's

Re: [proposed] 2.4 Maintenance SIG

On Thu, Jan 19, 2017 at 6:29 AM, Jim Jagielski wrote: > > Here's the real issue, as I see it. If there have been "recent > breakages" it is not due to the release process, but rather > the *testing* process. That is, not enough people testing > 2.4-HEAD until we actually get

Re: svn commit: r1779525 - /httpd/httpd/trunk/modules/http2/h2_mplx.c

> Am 19.01.2017 um 22:00 schrieb Ruediger Pluem : > On 01/19/2017 09:38 PM, ic...@apache.org wrote: >> Author: icing >> Date: Thu Jan 19 20:38:50 2017 >> New Revision: 1779525 >> >> URL: http://svn.apache.org/viewvc?rev=1779525=rev >> Log: >> On the trunk: >> >> mod_http2:

Re: [proposed] 2.4 Maintenance SIG

On Thu, Jan 19, 2017 at 2:52 PM, Noel Butler wrote: > > On 20/01/2017 05:54, William A Rowe Jr wrote: > >> posts, I don't think you will find a single post where I suggested >> that there is an issue with the frequency of releases, but please >> feel free. > > I believe

Re: mod_http2 and Frequent wake-ups for mpm_event

new segfault with both patches on top of v1.8.8: Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/usr/local/apache2/bin/httpd -k start'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7fbefce0d014 in ?? () from

Re: svn commit: r1779525 - /httpd/httpd/trunk/modules/http2/h2_mplx.c

On 01/19/2017 09:38 PM, ic...@apache.org wrote: > Author: icing > Date: Thu Jan 19 20:38:50 2017 > New Revision: 1779525 > > URL: http://svn.apache.org/viewvc?rev=1779525=rev > Log: > On the trunk: > > mod_http2: decoupling lifetime of mplx pool from h2_session which messed up > the cleanup

Re: clang-analyzer?

On 01/19/2017 09:07 PM, William A Rowe Jr wrote: > On Thu, Jan 19, 2017 at 1:30 PM, Ruediger Pluem wrote: >> >> If they are no-ops as you state in 3. how could they introduce regressions? > > They are still a text and code change. Cleaning up a cast, for example may > change

Re: [proposed] 2.4 Maintenance SIG

On 20/01/2017 05:54, William A Rowe Jr wrote: > posts, I don't think you will find a single post where I suggested > that there is an issue with the frequency of releases, but please > feel free. I believe that was me :) > You've put restated the argument again this month that if we > don't

Re: mod_http2 and Frequent wake-ups for mpm_event

On top please. There is only one way: forward! > Am 19.01.2017 um 21:47 schrieb Stefan Priebe - Profihost AG > : > > > Am 19.01.2017 um 21:39 schrieb Stefan Eissing: >> Thanks, Stefan. Can you given the attached Patch a try? > > sure. On top of the last one? Or should

Re: [proposed] 2.4 Maintenance SIG

There is no such thing as "Jim's Releases" or "Bill's Releases". The PMC votes on them and the release is an action of the PMC. It's a PMC release. As for why I do it: It's a chore. Mostly "thankless" due to the drama one needs to endure and the fact that you will be assured that at least someone

Re: mod_http2 and Frequent wake-ups for mpm_event

Am 19.01.2017 um 21:39 schrieb Stefan Eissing: > Thanks, Stefan. Can you given the attached Patch a try? sure. On top of the last one? Or should i drop it? Stefan >> Am 19.01.2017 um 19:33 schrieb Stefan Priebe : >> >> Here some more segfaults from 2.4.25 no mpm patch

Re: mod_http2 and Frequent wake-ups for mpm_event

Thanks, Stefan. Can you given the attached Patch a try? h2_mplx_pool_life.diff Description: Binary data > Am 19.01.2017 um 19:33 schrieb Stefan Priebe : > > Here some more segfaults from 2.4.25 no mpm patch but http2 v1.8.8: > >

Re: [proposed] 2.4 Maintenance SIG

> On Jan 19, 2017, at 3:12 PM, Jacob Champion wrote: > > I don't agree with everything Bill is saying here, but to be fair to him: if > people are backporting new features and higher-risk changes to 2.4.x at the > same time an RM is trying to coordinate a bugfix-only

Re: [proposed] 2.4 Maintenance SIG

On 01/19/2017 07:49 AM, Jim Jagielski wrote: You seem to be ignoring the times when bug-fixes, and regression-fix-only patches themselves have resulted in regressions. Sure, that does (and will continue to) happen. Every code change carries some risk, and no test suite is 100% perfect, but I

Re: clang-analyzer?

On Thu, Jan 19, 2017 at 1:30 PM, Ruediger Pluem wrote: > > If they are no-ops as you state in 3. how could they introduce regressions? They are still a text and code change. Cleaning up a cast, for example may change the alignment differently between various 32 and 64 bit

Re: [proposed] 2.4 Maintenance SIG

On Thu, Jan 19, 2017 at 6:29 AM, Jim Jagielski wrote: > >> On Jan 18, 2017, at 8:35 PM, Eric Covener wrote: >> >> On Wed, Jan 18, 2017 at 6:12 PM, William A Rowe Jr >> wrote: >>> I'm wondering if there is anyone interested in a

Re: clang-analyzer?

On 01/19/2017 08:16 PM, William A Rowe Jr wrote: > On Mon, Jan 9, 2017 at 3:48 AM, Graham Leggett wrote: >> On 08 Jan 2017, at 4:45 AM, Leif Hedstrom wrote: >> >>> I ran clang-analyzer against the HTTPD master branch, and it found 126 >>> issues. Many of

Re: Summary: Broken FastCGI with httpd

> On Jan 19, 2017, at 1:08 PM, David Zuelke wrote: > > Yeah, not much interest yet, sorry :( Jim, I think you have a php.net > account; are you also on that mailing list and can chime in? > It's been awhile... certainly before the Github switch. Don't *think* I'm on the

Re: clang-analyzer?

On Mon, Jan 9, 2017 at 3:48 AM, Graham Leggett wrote: > On 08 Jan 2017, at 4:45 AM, Leif Hedstrom wrote: > >> I ran clang-analyzer against the HTTPD master branch, and it found 126 >> issues. Many of these are benign, but I was curious if the community has

Re: Summary: Broken FastCGI with httpd

Let me mull this over... basically, we want/need to be able to read into the AddType directive the MIME type and the suffix and then look for the 1st occurance of a "file" with that suffix in the URL path and *assume* that is the actual SCRIPT_NAME. Being aware that this is virtual via the Action

Re: Summary: Broken FastCGI with httpd

> On Jan 19, 2017, at 1:00 PM, Jacob Champion wrote: > >> Would it make sense, mostly from a PHP point-of-view, to send >> something like SCRIPT_FILENAME_RAW (or even >> APACHE_SCRIPT_FILENAME)... Or does that simply complicate an already >> fuzzy and nebulous situation? >

Re: mod_http2 and Frequent wake-ups for mpm_event

Here some more segfaults from 2.4.25 no mpm patch but http2 v1.8.8: # Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/usr/local/apache2/bin/httpd -k start'. Program terminated with

Re: Summary: Broken FastCGI with httpd

On 19.01.2017, at 19:00, Jacob Champion wrote: > > On 01/18/2017 01:00 PM, Jim Jagielski wrote: >> After all, it's easier for the FCGI server to know the SCRIPT_NAME >> than httpd to "guess"... > > I think the recent breakage calls this assumption into question. The server

Re: Summary: Broken FastCGI with httpd

On 01/18/2017 01:00 PM, Jim Jagielski wrote: After all, it's easier for the FCGI server to know the SCRIPT_NAME than httpd to "guess"... I think the recent breakage calls this assumption into question. The server admin knows exactly where the scripts are in the use cases we're currently

Re: Summary: Broken FastCGI with httpd

Would it make sense, mostly from a PHP point-of-view, to send something like SCRIPT_FILENAME_RAW (or even APACHE_SCRIPT_FILENAME)... Or does that simply complicate an already fuzzy and nebulous situation? Is [1] being used as the canonical place for this discussion w/ the PHP Group? 1.

Re: [proposed] 2.4 Maintenance SIG

You seem to be ignoring the times when bug-fixes, and regression-fix-only patches themselves have resulted in regressions. Or when bug-fixes themselves devolve into grand-scale refactoring which greatly introduce the very real probability of regressions. Handling regressions seems independent

Re: mod_http2 and Frequent wake-ups for mpm_event

On Thu, Jan 19, 2017 at 4:45 PM, Stefan Priebe - Profihost AG wrote: > > Am 19.01.2017 um 16:34 schrieb Stefan Eissing: >> Yann might already have asked this: any chance to compile with symbols and >> get a more readable stacktrace? > > Yes just tell me how ;-) i'm using

Re: mod_http2 and Frequent wake-ups for mpm_event

arg sorry my fault. Here is a complete trace: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7fc1c23e0f23 in apr_brigade_length () from /usr/lib/x86_64-linux-gnu/libaprutil-1.so.0 (gdb) bt #0 0x7fc1c23e0f23 in apr_brigade_length () from

Re: mod_http2 and Frequent wake-ups for mpm_event

Am 19.01.2017 um 16:34 schrieb Stefan Eissing: > Yann might already have asked this: any chance to compile with symbols and > get a more readable stacktrace? Yes just tell me how ;-) i'm using dpkg-buildpackage and dh_strip. I've no idea why not all symbols are available. Do i need to pass a

Re: mod_http2 and Frequent wake-ups for mpm_event

Yann might already have asked this: any chance to compile with symbols and get a more readable stacktrace? > Am 19.01.2017 um 16:30 schrieb Stefan Priebe - Profihost AG > : > > With stock 2.4.25 + patch i'm getting this one again: > (gdb) bt > #0 0x00521dcd in

Re: mod_http2 and Frequent wake-ups for mpm_event

On Thu, Jan 19, 2017 at 4:28 PM, Stefan Priebe - Profihost AG wrote: > > May this configure option have an influence? > --enable-nonportable-atomics=yes Sure, for speed, but not correctness ("yes" never caused an issue for me/linux, AFAICT).

Re: mod_http2 and Frequent wake-ups for mpm_event

With stock 2.4.25 + patch i'm getting this one again: (gdb) bt #0 0x00521dcd in h2_stream_out_prepare () #1 0x7fc1a2feca80 in ?? () #2 0x7fc1a2feca8c in ?? () #3 0x7fc1a2feca90 in ?? () #4 0x7fc1a057c0a0 in ?? () #5 0x7fc1a057cdd8 in ?? () #6 0x7fc1a2fecac0

Re: mod_http2 and Frequent wake-ups for mpm_event

I'm now testing stock 2.4.25 + patch. May this configure option have an influence? --enable-nonportable-atomics=yes Greets, Stefan Am 19.01.2017 um 15:35 schrieb Yann Ylavic: > Hi, > > On Thu, Jan 19, 2017 at 3:00 PM, Stefan Priebe - Profihost AG > wrote: >> >> @Yann:

Re: mod_http2 and Frequent wake-ups for mpm_event

This one is with mod_http2 v1.8.8 + http2 patch - no mpm patch. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7f1aa4c45d63 in apr_pool_cleanup_kill () from /usr/lib/x86_64-linux-gnu/libapr-1.so.0 (gdb) bt #0 0x7f1aa4c45d63 in apr_pool_cleanup_kill () from

Re: mod_http2 and Frequent wake-ups for mpm_event

Am 19.01.2017 um 15:05 schrieb Stefan Eissing: > I prefer on top of v1.8.8, but it's your installation. Should also work on > older versions. got this one: (gdb) bt #0 0x7f4c424ec014 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7f4c4297f036 in ?? () from

Re: mod_http2 and Frequent wake-ups for mpm_event

Hi, On Thu, Jan 19, 2017 at 3:00 PM, Stefan Priebe - Profihost AG wrote: > > @Yann: > should i use V7 or V6? I'd prefer you'd use none (such that we can verify the patch with stock 2.4.25, modulo mod_http2), but if it's easier for you to reproduce with an event's patch,

Re: mod_http2 and Frequent wake-ups for mpm_event

I prefer on top of v1.8.8, but it's your installation. Should also work on older versions. > Am 19.01.2017 um 15:00 schrieb Stefan Priebe - Profihost AG > : > > Hi, > > on top of v1.8.8? > > @Yann: > should i use V7 or V6? > > Stefan > > Am 19.01.2017 um 14:56

Re: mod_http2 and Frequent wake-ups for mpm_event

Hi, on top of v1.8.8? @Yann: should i use V7 or V6? Stefan Am 19.01.2017 um 14:56 schrieb Stefan Eissing: > Stefan, > > could you check if the attached patch mitigates the problem at least to some > extend? Was suggested to me by Yann, all faults are mine. Thanks! > > Cheers, Stefan > > >

Re: mod_http2 and Frequent wake-ups for mpm_event

Stefan, could you check if the attached patch mitigates the problem at least to some extend? Was suggested to me by Yann, all faults are mine. Thanks! Cheers, Stefan h2_session_clean.diff Description: Binary data > Am 19.01.2017 um 12:45 schrieb Stefan Priebe - Profihost AG >

Re: [proposed] 2.4 Maintenance SIG

On Thu, Jan 19, 2017 at 8:22 AM, Stefan Eissing wrote: > > It will surprise no one that I like to release more often. OTOH I do > not like to break things. > > The current release model clearly does not work well, in my limited > experience over that last 15 months.

Re: [proposed] 2.4 Maintenance SIG

> On Jan 18, 2017, at 8:35 PM, Eric Covener wrote: > > On Wed, Jan 18, 2017 at 6:12 PM, William A Rowe Jr > wrote: >> I'm wondering if there is anyone interested in a regression-fix-only 2.4.26 >> that >> finally proves to be a workable upgrade for all

Re: mod_http2 and Frequent wake-ups for mpm_event

Am 19.01.2017 um 11:56 schrieb Stefan Eissing: > Stefan, > > yes, that is a known one that was addressed in v1.8.7. But I think it is > related to the others. There is some mistake in my thinking about session > pool cleanup that is more often uncovered by Yann's recent patches. I'll need >

Re: mod_fcgi: Excessive memory usage when large files are uploaded

Hello, It turns out that there is an existing bug report for this since year 2011: https://bz.apache.org/bugzilla/show_bug.cgi?id=51747 The latest proposed patch by Jan Stürtz on 2015-08-28 fixes both the Linux and Windows versions and still applies OK. Furthermore,

Re: mod_http2 and Frequent wake-ups for mpm_event

Stefan, yes, that is a known one that was addressed in v1.8.7. But I think it is related to the others. There is some mistake in my thinking about session pool cleanup that is more often uncovered by Yann's recent patches. I'll need some deep dive into this one. For you, that means v1.8.8 is

Re: [proposed] 2.4 Maintenance SIG

> Am 19.01.2017 um 10:08 schrieb Reindl Harald : > Am 19.01.2017 um 08:22 schrieb Stefan Eissing: >> Distros seem to have realized the problem long ago and make their own httpd >> versions. First time I realized my "httpd 2.4.7" is not the 2.4.7 release >> was a WTF

Re: mod_http2 and Frequent wake-ups for mpm_event

Hi, with V7 and mod_http2 core i'm always seeing exactly THIS trace and instead of every few minutes just once an hour: [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/apache2/bin/httpd -k

Re: [proposed] 2.4 Maintenance SIG

Am 19.01.2017 um 08:22 schrieb Stefan Eissing: Distros seem to have realized the problem long ago and make their own httpd versions. First time I realized my "httpd 2.4.7" is not the 2.4.7 release was a WTF moment. no, that applies to LTS distros and in that case of nearly any piece of

Re: mod_http2 and Frequent wake-ups for mpm_event

And another one: #0 0x7f7d81ba1f23 in apr_brigade_length () from /usr/lib/x86_64-linux-gnu/libaprutil-1.so.0 (gdb) bt #0 0x7f7d81ba1f23 in apr_brigade_length () from /usr/lib/x86_64-linux-gnu/libaprutil-1.so.0 #1 0x0052a8bc in h2_util_bb_avail () #2 0x7112ca10 in ?? ()

Re: mod_http2 and Frequent wake-ups for mpm_event

Hi, Am 19.01.2017 um 09:11 schrieb Yann Ylavic: > On Thu, Jan 19, 2017 at 9:05 AM, Stefan Priebe - Profihost AG > wrote: >> With a vanilla apache 2.4.25 i got this one: >> >> Core was generated by `/usr/local/apache2/bin/httpd -k start'. >> Program terminated with signal

Re: mod_http2 and Frequent wake-ups for mpm_event

On Thu, Jan 19, 2017 at 9:05 AM, Stefan Priebe - Profihost AG wrote: > With a vanilla apache 2.4.25 i got this one: > > Core was generated by `/usr/local/apache2/bin/httpd -k start'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x7fe2bb7b8add in

Re: mod_http2 and Frequent wake-ups for mpm_event

With a vanilla apache 2.4.25 i got this one: Core was generated by `/usr/local/apache2/bin/httpd -k start'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7fe2bb7b8add in read () from /lib/x86_64-linux-gnu/libpthread.so.0 (gdb) bt #0 0x7fe2bb7b8add in read () from