> Am 25.08.2021 um 15:15 schrieb ste...@eissing.org:
>
>
>
>> Am 25.08.2021 um 15:06 schrieb ste...@eissing.org:
>>
>>
>>
>>> Am 25.08.2021 um 13:53 schrieb Yann Ylavic <ylavic....@gmail.com>:
>>>
>>> On Wed, Aug 25, 2021 at 1:14 AM Travis CI <bui...@travis-ci.com> wrote:
>>>>
>>>> apache / httpd
>>>>
>>>> trunk
>>>>
>>>> Build #1831 was broken
>>>> 21 mins and 33 secs
>>>> Yann Ylavic
>>>> 243c5fa CHANGESET →
>>>>
>>>> mpm_{event,worker,prefork}: late stop of children processes on restart.
>>>
>>> (unrelated to this change, Build #1819 failed the same earlier).
>>>
>>> Here: https://app.travis-ci.com/github/apache/httpd/jobs/533578536#L4103
>>>
>>> It seems that when exiting a stream can be destroyed while in
>>> h2_mplx_s_task_done::s_task_done()::mst_check_data_for()
>>> when the mplx lock is released (thus stream->id faults).
>>>
>>> Should the caller(s) of mst_check_data_for() pass stream->id (under
>>> the lock) instead?
>>> This would avoid the fault but that's still a potentially destroyed
>>> stream being fifo'ed, though we are exiting so it might not matter..
>>>
>>> A better fix maybe, Stefan?
>>
>> I think the "stream->id" needs to be save before giving up the lock.
>> I'll make the change, but currently my test suite throws several
>> other errors in trunk. Something changed...
>>
>> Btw. I am working on a real fix of this messy code in http2, using
>> a apr_pollset for monitoring connections and ongoing requests. Also
>> cleaning up other parts of the code, reducing complexity.
>>
>> <https://github.com/icing/mod_h2/tree/icing/pipes>
>>
>> I'll see what version of trunk still runs my tests and report back.
>
>
> Ok, r1892586 still runs the http2 tests nicely. Seems that r1892587
> broke things. Note that the http2 test suite does a lot of server
> reloads.
Follow up: if I do a "time.sleep(2)" after each "apachectl" in my
test suite, it works fine.
Speculating: my test suite does commonly a GET after a reload to
see if the reloaded server is responding. And then fires requests
against the new configuration.
Now, if the server is always responding, the test sill get - sometimes -
send request to an old gen child which then answers incorrectly. So
I see 404 responses where a 200 should be as the config does not match.
In this new world of always responding servers, when is a test suite
supposed to know that now the server will respond with the newly laoded
config?
- Stefan
>
> Stefan
>
>>
>> - Stefan
>>
>>>
>>> Cheers;
>>> Yann.
