> Am 20.02.2017 um 10:36 schrieb Stefan Priebe :
>
> Hi,
>
> still not a single segfault with mod_http2 1.9.0 - good work!
Thanks! Our pleasure. Enjoy it until I break something in the next releases.
> @Yann
> Could you please tell me whether i should drop of your additional patches?
>
> Gre
On Mon, Feb 20, 2017 at 10:36 AM, Stefan Priebe wrote:
>
> @Yann
> Could you please tell me whether i should drop of your additional patches?
Sorry Stefan, somehow I missed you message.
I'll reply (inline) on the other thread.
Hi,
still not a single segfault with mod_http2 1.9.0 - good work!
@Yann
Could you please tell me whether i should drop of your additional patches?
Greets,
Stefan
Am 09.02.2017 um 11:55 schrieb Stefan Priebe - Profihost AG:
Hi Stefan,
Am 09.02.2017 um 11:47 schrieb Stefan Eissing:
Stefan,
a
Hi Stefan,
Am 09.02.2017 um 11:47 schrieb Stefan Eissing:
> Stefan,
>
> at this point and after several efforts to write the right patch, I reached
> the conclusion that I need to rethink the pool hierarchy and connection
> shutdown strategy in mod_http2. The current, organically grown implemen
Stefan,
at this point and after several efforts to write the right patch, I reached the
conclusion that I need to rethink the pool hierarchy and connection shutdown
strategy in mod_http2. The current, organically grown implementation needs a
refactor with the knowledge we have made so far.
So,
Hi,
got this one today with both patches applied:
Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 allocator_free (node=0x0, allocator=0x7f350405e030)
at memory/unix/apr_pools.c:381
#0 allocator_free (node=0x0,
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
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:
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 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
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: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
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?
>
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 :
>>
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
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 ;)
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'
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 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
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 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 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
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
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
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
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
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
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 Stefan,
On Sun, Feb 5, 2017 at 7:51 PM, Stefan Priebe - 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
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 0x7ff523558067 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#0 0x7ff523558067 in raise () from /lib
Am 02.02.2017 um 11:09 schrieb Yann Ylavic:
> Hi Stefan,
>
> On Tue, Jan 31, 2017 at 4:01 PM, Stefan Priebe - Profihost AG
> wrote:
>>
>> any ideas?
>
> I wonder if the attached patch (related to mod_ssl and proposed for
> another segfault report) could help in your case.
>
> Would you mind gi
Hi Stefan,
On Tue, Jan 31, 2017 at 4:01 PM, Stefan Priebe - Profihost AG
wrote:
>
> any ideas?
I wonder if the attached patch (related to mod_ssl and proposed for
another segfault report) could help in your case.
Would you mind give it a try?
Thanks,
Yann.
Index: modules/ssl/ssl_engine_io.c
=
As Rüdiger wrote, this stacktrace does not make any sense (to me), unless the
pool cleanup messes up the stack.
Hmmm. This points to a major misconception of mine how things are supposed to
happen. Will continue to look at this, but no easy solution in sight.
> Am 27.01.2017 um 20:30 schrieb Ru
Am 01.02.2017 um 06:36 schrieb Stefan Eissing:
Stefan,
did not have the time to look at it really. Will do, but very busy right now.
Thanks - no problem.
Am 31.01.2017 um 16:01 schrieb Stefan Priebe - Profihost AG
:
Hi Yann,
Hi Stefan,
any ideas?
Stefan
Am 27.01.2017 um 20:30 schrie
Stefan,
did not have the time to look at it really. Will do, but very busy right now.
> Am 31.01.2017 um 16:01 schrieb Stefan Priebe - Profihost AG
> :
>
> Hi Yann,
> Hi Stefan,
>
> any ideas?
>
> Stefan
>
>> Am 27.01.2017 um 20:30 schrieb Ruediger Pluem:
>>
>>
>>> On 01/27/2017 08:10 PM
Hi Yann,
Hi Stefan,
any ideas?
Stefan
Am 27.01.2017 um 20:30 schrieb Ruediger Pluem:
>
>
> On 01/27/2017 08:10 PM, Stefan Priebe - Profihost AG wrote:
>> Hi Yann,
>>
>> this is now a segfault with mod_http2 + beam v4 patch + mpm v7 patch:
>> Program terminated with signal SIGSEGV, Segmentati
On 01/27/2017 08:10 PM, Stefan Priebe - Profihost AG wrote:
> Hi Yann,
>
> this is now a segfault with mod_http2 + beam v4 patch + mpm v7 patch:
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 allocator_free (node=0x0, allocator=0x7f8974080c90)
> at memory/unix/apr_pools.
Hi Yann,
this is now a segfault with mod_http2 + beam v4 patch + mpm v7 patch:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 allocator_free (node=0x0, allocator=0x7f8974080c90)
at memory/unix/apr_pools.c:381
#0 allocator_free (node=0x0, allocator=0x7f8974080c90)
at memor
Am 25.01.2017 um 10:46 schrieb Stefan Eissing:
> Thanks Yann!
>
> Stefan: here is the patch as committed to trunk:
Up and running. Will report back.
>
>
> Cheers, Stefan
>
>> Am 25.01.2017 um 01:41 schrieb Yann Ylavic :
>>
>> Hi Stefan,
>>
>> On Tue, Jan 24, 2017 at 1:37 PM, Stefan Eissing
>>
Thanks Yann!
Stefan: here is the patch as committed to trunk:
h2_beams_cleanup_v4.diff
Description: Binary data
Cheers, Stefan
> Am 25.01.2017 um 01:41 schrieb Yann Ylavic :
>
> Hi Stefan,
>
> On Tue, Jan 24, 2017 at 1:37 PM, Stefan Eissing
> wrote:
>> Yann, thanks for the patch. I agree
> Am 25.01.2017 um 08:04 schrieb Stefan Priebe - Profihost AG
> :
>
> Hi Yann,
>
>> Am 25.01.2017 um 01:41 schrieb Yann Ylavic:
>> Hi Stefan,
>>
>> On Tue, Jan 24, 2017 at 1:37 PM, Stefan Eissing
>> wrote:
>>> Yann, thanks for the patch. I agree that the cleanups need to be killed in
>>> th
Hi Yann,
Am 25.01.2017 um 01:41 schrieb Yann Ylavic:
> Hi Stefan,
>
> On Tue, Jan 24, 2017 at 1:37 PM, Stefan Eissing
> wrote:
>> Yann, thanks for the patch. I agree that the cleanups need to be killed in
>> the right place. Not certain if it was wrong before, but that part is not
>> easy to s
On Wed, Jan 25, 2017 at 1:43 AM, Yann Ylavic wrote:
> Hi,
>
> On Tue, Jan 24, 2017 at 4:09 PM, Stefan Priebe - Profihost AG
> wrote:
>>
>> Thanks. Would currently wait if you had a look at stefans patch. Or
>> isn't that the same but "better"?
>
> Could you please give "h2_beams_cleanup_v3.diff"
Hi,
On Tue, Jan 24, 2017 at 4:09 PM, Stefan Priebe - Profihost AG
wrote:
>
> Thanks. Would currently wait if you had a look at stefans patch. Or
> isn't that the same but "better"?
Could you please give "h2_beams_cleanup_v3.diff" (from previous message) a try?
Thanks Stefan.
Hi Stefan,
On Tue, Jan 24, 2017 at 1:37 PM, Stefan Eissing
wrote:
> Yann, thanks for the patch. I agree that the cleanups need to be killed in
> the right place. Not certain if it was wrong before, but that part is not
> easy to see for every combination.
>
> I did some rework and hope this mak
Am 24.01.2017 um 14:22 schrieb Yann Ylavic:
> On Tue, Jan 24, 2017 at 10:02 AM, Stefan Priebe - Profihost AG
> wrote:
>>
>> Am 23.01.2017 um 23:42 schrieb Yann Ylavic:
>>> On Mon, Jan 23, 2017 at 11:37 PM, Yann Ylavic wrote:
Hi Stefan,
On Mon, Jan 23, 2017 at 9:54 PM, Stefan Eissi
On Tue, Jan 24, 2017 at 10:02 AM, Stefan Priebe - Profihost AG
wrote:
>
> Am 23.01.2017 um 23:42 schrieb Yann Ylavic:
>> On Mon, Jan 23, 2017 at 11:37 PM, Yann Ylavic wrote:
>>> Hi Stefan,
>>>
>>> On Mon, Jan 23, 2017 at 9:54 PM, Stefan Eissing
>>> wrote:
I am not aware of any special
Yann, thanks for the patch. I agree that the cleanups need to be killed in the
right place. Not certain if it was wrong before, but that part is not easy to
see for every combination.
I did some rework and hope this makes it more readable. If you find the time to
look at it, feedback welcome.
Am 23.01.2017 um 23:42 schrieb Yann Ylavic:
> On Mon, Jan 23, 2017 at 11:37 PM, Yann Ylavic wrote:
>> Hi Stefan,
>>
>> On Mon, Jan 23, 2017 at 9:54 PM, Stefan Eissing
>> wrote:
>>>
>>> I am not aware of any special expectations now. Almost all is triggered by
>>> (parent) pool cleanups and is t
On Mon, Jan 23, 2017 at 11:37 PM, Yann Ylavic wrote:
> Hi Stefan,
>
> On Mon, Jan 23, 2017 at 9:54 PM, Stefan Eissing
> wrote:
>>
>> I am not aware of any special expectations now. Almost all is triggered by
>> (parent) pool cleanups and is therefore more deterministic than before. The
>> only
Hi Stefan,
On Mon, Jan 23, 2017 at 9:54 PM, Stefan Eissing
wrote:
>
> I am not aware of any special expectations now. Almost all is triggered by
> (parent) pool cleanups and is therefore more deterministic than before. The
> only explicit destroy is done on finished streams and slave connection
Am 23.01.2017 um 21:54 schrieb Stefan Eissing:
>
>> Am 22.01.2017 um 22:22 schrieb Yann Ylavic :
>>
>> @icing: Any special expectation in mod_h2 with regard to mpm workers
>> threads' lifetime (or keepalive connections that should stay alive for
>> the configured limit)?
>> I see that beam bucket
> Am 22.01.2017 um 22:22 schrieb Yann Ylavic :
>
> @icing: Any special expectation in mod_h2 with regard to mpm workers
> threads' lifetime (or keepalive connections that should stay alive for
> the configured limit)?
> I see that beam buckets make use of thread local storage/keys for
> locking,
Am 22.01.2017 um 22:22 schrieb Yann Ylavic:
> Hi Stefan,
>
> On Sun, Jan 22, 2017 at 8:00 PM, Stefan Priebe - Profihost AG
> wrote:
>> Am 22.01.2017 um 18:02 schrieb Eric Covener:
>>> On Sun, Jan 22, 2017 at 11:21 AM, Stefan Priebe - Profihost AG
>>> wrote:
Hi Stefan,
no i was mis
Hi Stefan,
On Sun, Jan 22, 2017 at 8:00 PM, Stefan Priebe - Profihost AG
wrote:
> Am 22.01.2017 um 18:02 schrieb Eric Covener:
>> On Sun, Jan 22, 2017 at 11:21 AM, Stefan Priebe - Profihost AG
>> wrote:
>>> Hi Stefan,
>>>
>>> no i was mistaken customer isn't using mod_proxy - but I think this is
Am 22.01.2017 um 18:02 schrieb Eric Covener:
> On Sun, Jan 22, 2017 at 11:21 AM, Stefan Priebe - Profihost AG
> wrote:
>> Hi Stefan,
>>
>> no i was mistaken customer isn't using mod_proxy - but I think this is
>> the patch causing me problems:
>> https://github.com/apache/httpd/commit/a61a4bd02e48
On Sun, Jan 22, 2017 at 11:21 AM, Stefan Priebe - Profihost AG
wrote:
> Hi Stefan,
>
> no i was mistaken customer isn't using mod_proxy - but I think this is
> the patch causing me problems:
> https://github.com/apache/httpd/commit/a61a4bd02e483fb45d433343740d0130ee3d8d5d
>
> What do you think?
>
Not my forté. Yann probably has a better idea here. Let's see if he has time to
look at it tomorrow.
> Am 22.01.2017 um 17:21 schrieb Stefan Priebe - Profihost AG
> :
>
> Hi Stefan,
>
> no i was mistaken customer isn't using mod_proxy - but I think this is
> the patch causing me problems:
> ht
Hi Stefan,
no i was mistaken customer isn't using mod_proxy - but I think this is
the patch causing me problems:
https://github.com/apache/httpd/commit/a61a4bd02e483fb45d433343740d0130ee3d8d5d
What do you think?
Greets,
Stefan
Am 22.01.2017 um 17:17 schrieb Stefan Eissing:
>
>> Am 22.01.2017 u
> Am 22.01.2017 um 17:14 schrieb Stefan Priebe - Profihost AG
> :
>
> *arg* it's just mod_proxy - just saw thread safety and apr bucket aloc.
??? Can you elaborate? Is your finding the known hcheck bug or something else?
> Stefan
>
> Am 22.01.2017 um 17:06 schrieb Stefan Priebe - Profihost AG
*arg* it's just mod_proxy - just saw thread safety and apr bucket aloc.
Stefan
Am 22.01.2017 um 17:06 schrieb Stefan Priebe - Profihost AG:
> Looks like others have the same crashes too:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=60071
> and
> https://github.com/apache/httpd/commit/8e63c3c9
Looks like others have the same crashes too:
https://bz.apache.org/bugzilla/show_bug.cgi?id=60071
and
https://github.com/apache/httpd/commit/8e63c3c9372cd398f57357099aa941cbba695758
So it looks like mod_http2 is running fine now. Thanks a lot Stefan.
Yann i think i can start testing your mpm patc
Hi,
and a new one but also in ap_start_lingering_close:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 apr_palloc (pool=pool@entry=0x7f455805e138, in_size=in_size@entry=32)
at memory/unix/apr_pools.c:684
#0 apr_palloc (pool=pool@entry=0x7f455805e138, in_size=in_size@entry=3
All last traces come from event, proces_longering_close ap_push_pool but
end in different functions. It looks like a race somewhere and it just
races at different function in the event of close and pool clear.
Might there be two places where the same pool gets cleared?
Stefan
Am 21.01.2017 um
Hi Stefan,
thanks. No crashes where h2 comes up. But i still have these and no idea
how to find out who and why they're crashing.
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 si
Am 21.01.2017 um 17:03 schrieb Stefan Eissing:
Stefan,
made a release at https://github.com/icing/mod_h2/releases/tag/v1.8.9 with all
patches and improved (hopefully) on them a bit. If you dare to drop that into
your installation, that'd be great.
thx it's running - will report back shortly.
Stefan,
made a release at https://github.com/icing/mod_h2/releases/tag/v1.8.9 with all
patches and improved (hopefully) on them a bit. If you dare to drop that into
your installation, that'd be great.
Cheers,
Stefan
> Am 21.01.2017 um 15:25 schrieb Stefan Priebe :
>
> and i got another crash
and i got another crash here:
2346 static void run_cleanups(cleanup_t **cref)
2347 {
2348 cleanup_t *c = *cref;
2349
2350 while (c) {
2351 *cref = c->next;
2352 (*c->plain_cleanup_fn)((void *)c->data); <== here
2353 c = *cref;
2354
which looks similar to the oth
Hi,
#0 apr_pool_cleanup_kill (p=0x7fe4a8072358,
data=data@entry=0x7fe4a80723e0,
cleanup_fn=cleanup_fn@entry=0x7fe4bbd38a40 ) at
memory/unix/apr_pools.c:2276
it crashes here in apr:
2276 if (c->data == data && c->plain_cleanup_fn == cleanup_fn) {
some lines before c becomes this
Hi Yann,
looks better so far. This is the only one i got without mpm patch:
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 apr_pool_cleanup_ki
Hi Stefan,
On Sat, Jan 21, 2017 at 9:45 AM, Stefan Priebe wrote:
>
> after running the whole night. These are the only ones still happening.
> Should i revert the mpm patch to check whether it's the source?
Yes please, we need to determine...
Thanks,
Yann.
Hi,
after running the whole night. These are the only ones still happening.
Should i revert the mpm patch to check whether it's the source? I'm only
seeing one related to mod_http2.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_
Hi,
this patch solved the file_close segfault. Never saw that again.
Right now i got this one:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x7f129f612274 in pthread_mutex_lock () from
/lib/x86_64-linux-gnu/libpthread.so.0
(gdb) bt
#0 0x7f129f612274 in pthread_mutex_l
Am 20.01.2017 um 18:17 schrieb Yann Ylavic:
> On Fri, Jan 20, 2017 at 5:51 PM, Stefan Priebe - Profihost AG
> wrote:
>> Yes. Until now I got 4 traces. But all are the same pointing to apr kill
>> pool. Not like before where i got many different ones.
>
> Could you try this new patch on mod_http2
Good catch, Yann.
I have local modifications that throw most of the manual cleanup out and rely
on auto pool cleanup as much as possible. Curious if that will solve Stefan's
crashes.
> Am 20.01.2017 um 18:17 schrieb Yann Ylavic :
>
> On Fri, Jan 20, 2017 at 5:51 PM, Stefan Priebe - Profihost
On Fri, Jan 20, 2017 at 5:51 PM, Stefan Priebe - Profihost AG
wrote:
> Yes. Until now I got 4 traces. But all are the same pointing to apr kill
> pool. Not like before where i got many different ones.
Could you try this new patch on mod_http2 please?
Thanks,
Yann.
Index: modules/http2/h2_stream.
Yes. Until now I got 4 traces. But all are the same pointing to apr kill pool.
Not like before where i got many different ones.
Greets,
Stefan
Excuse my typo sent from my mobile phone.
> Am 20.01.2017 um 17:44 schrieb Yann Ylavic :
>
> On Fri, Jan 20, 2017 at 5:41 PM, Stefan Priebe - Profihost
On Fri, Jan 20, 2017 at 5:41 PM, Stefan Priebe - Profihost AG
wrote:
> Sorry misstyped it's V7 with mod_http 1.8.8 unpatched.
Unpatched but still compiled with -fno-strict-aliasing (along with APR)?
Thanks,
Yann.
Sorry misstyped it's V7 with mod_http 1.8.8 unpatched.
Stefan
Excuse my typo sent from my mobile phone.
> Am 20.01.2017 um 16:23 schrieb Stefan Priebe - Profihost AG
> :
>
> Hi,
>
> it crashed again with V6 and plain mod_http2 v1.8.8.
>
> This is the crash incl. line numbers:
> Program termi
Hi,
it crashed again with V6 and plain mod_http2 v1.8.8.
This is the crash incl. line numbers:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 apr_pool_cleanup_kill (p=0x2d392d322d32,
data=data@entry=0x7f330006bc70,
cleanup_fn=cleanup_fn@entry=0x7f33155b0f90 )
at memory/un
Please use V7 too, I don't think I'll revert it in trunk (it makes sense).
On Fri, Jan 20, 2017 at 1:20 PM, Stefan Eissing
wrote:
> Please without. Then I least know if that version behaves. Planning on more
> extensive changes for a 1.9.0 now. Thanks!
>
> -Stefan
>
>> Am 20.01.2017 um 13:18 sch
Please without. Then I least know if that version behaves. Planning on more
extensive changes for a 1.9.0 now. Thanks!
-Stefan
> Am 20.01.2017 um 13:18 schrieb Stefan Priebe - Profihost AG
> :
>
> Will start retesting V6 patch. Should I use mod_http2 1.8.8 with or without
> patches?
>
> Gree
Will start retesting V6 patch. Should I use mod_http2 1.8.8 with or without
patches?
Greets,
Stefan
Excuse my typo sent from my mobile phone.
> Am 20.01.2017 um 13:04 schrieb Stefan Eissing :
>
> Different apr versions? Might there have been a bugfix affecting us?
>
>> Am 20.01.2017 um 12:49
Different apr versions? Might there have been a bugfix affecting us?
> Am 20.01.2017 um 12:49 schrieb Stefan Priebe - Profihost AG
> :
>
> might this be a debian bug? i can't reproduce with apr-included.
>
> Am 20.01.2017 um 08:20 schrieb Yann Ylavic:
>> Hi,
>>
>> On Fri, Jan 20, 2017 at 8:03
On Fri, Jan 20, 2017 at 12:49 PM, Stefan Priebe - Profihost AG
wrote:
> might this be a debian bug? i can't reproduce with apr-included.
Did you build the included-apr (and httpd) with -fno-strict-aliasing ?
Not sure Debian sets it for its builds either, just a speculation (I
used to have issues
might this be a debian bug? i can't reproduce with apr-included.
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 ch
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:
>>> - can you compile the mod
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 the trace?
>
> Do you h
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 A
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 the
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 /lib/x86_64-lin
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 i drop it?
>
>
> Stefa
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 but http2 v1.8.8:
>>
>>
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:
>
> ###
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
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 dpkg-buildpackage and dh_
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
/usr/lib/x86_64-linux-gnu/libapru
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 sp
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 h2_stream_out_prepare ()
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).
1 - 100 of 141 matches
Mail list logo