httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Priebe <s.pri...@profihost.ag>
Subject Re: mod_http2 and Frequent wake-ups for mpm_event
Date Sat, 21 Jan 2017 16:08:22 GMT
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

> Cheers,
>
> Stefan
>
>> Am 21.01.2017 um 15:25 schrieb Stefan Priebe <s.priebe@profihost.ag>:
>>
>> 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 other crash.
>>
>> #0  0x00007fe4bbd33e1b in run_cleanups (cref=<optimized out>) at memory/unix/apr_pools.c:2352
>> #1  apr_pool_clear (pool=0x7fe4a804dac8) at memory/unix/apr_pools.c:772
>> #2  0x00000000004feb38 in ap_push_pool (queue_info=0x6d616e79642d3733, pool_to_recycle=0x2)
at fdqueue.c:234
>> #3  0x00000000004fa8d8 in process_lingering_close (cs=0x7fe4a804dd58, pfd=0x25d3f98)
at event.c:1439
>>
>> Details:
>> (gdb) print c
>> $1 = (cleanup_t *) 0x7fe4a804e9f0
>> (gdb) print *c
>> $2 = {next = 0x7fe4a804e870, data = 0x6d616e79642d3733, plain_cleanup_fn = 0x392d3734322e6369,
>>  child_cleanup_fn = 0x617465722e722d35}
>> (gdb) print *c->data
>> Attempt to dereference a generic pointer.
>> (gdb) print *c->plain_cleanup_fn
>> Cannot access memory at address 0x392d3734322e6369
>> (gdb)
>>
>> Stefan
>>
>> Am 21.01.2017 um 15:18 schrieb Stefan Priebe:
>>> Hi,
>>>
>>> #0  apr_pool_cleanup_kill (p=0x7fe4a8072358,
>>> data=data@entry=0x7fe4a80723e0,
>>>    cleanup_fn=cleanup_fn@entry=0x7fe4bbd38a40 <socket_cleanup>) 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
>>> 2264     c = p->cleanups;
>>>
>>> p is:
>>> (gdb) print *p
>>> $1 = {parent = 0x256f138, child = 0x7fe46c0751c8, sibling =
>>> 0x7fe4a8096888, ref = 0x7fe4a8069fe8, cleanups = 0x7fe478159748,
>>>  free_cleanups = 0x7fe478159788, allocator = 0x7fe4a803b490,
>>> subprocesses = 0x0, abort_fn = 0x43da00 <abort_on_oom>,
>>>  user_data = 0x0, tag = 0x502285 "transaction", active =
>>> 0x7fe478158d70, self = 0x7fe4a8072330,
>>>  self_first_avail = 0x7fe4a80723d0 "X#\a\250\344\177", pre_cleanups =
>>> 0x7fe4a8072ab8}
>>>
>>> wouldn't the error mean that p->cleanups is NULL?
>>>
>>> (gdb) print *p->cleanups
>>> $2 = {next = 0x7fe478159628, data = 0x7fe478159648, plain_cleanup_fn =
>>> 0x7fe4bbd2ffd0 <apr_unix_file_cleanup>,
>>>  child_cleanup_fn = 0x7fe4bbd2ff70 <apr_unix_child_file_cleanup>}
>>>
>>> So p->cleanups->data is 0x7fe478159648 and data is 0x7fe4a80723e0?
>>>
>>> I don't get why it's segfaulting
>>>
>>> Stefan
>>> Am 21.01.2017 um 09:50 schrieb Yann Ylavic:
>>>> Hi Stefan,
>>>>
>>>> On Sat, Jan 21, 2017 at 9:45 AM, Stefan Priebe <s.priebe@profihost.ag>
>>>> 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.
>>>>
>
> Stefan Eissing
>
> <green/>bytes GmbH
> Hafenstrasse 16
> 48155 M√ľnster
> www.greenbytes.de
>

Mime
View raw message