On Mon, Nov 23, 2020 at 10:17 AM Joe Orton <jor...@redhat.com> wrote:
>
> On Fri, Nov 20, 2020 at 06:08:18PM +0100, Yann Ylavic wrote:
> > I tried to reproduce this failure locally (debian buster) with multiple
> > tries but couldn't.
> > I think I'm using the same environment (apr-1.7.0, apr-util-1.6.1,
> > APR_POOL_DEBUG, docker.io/redis:latest), and in the same way running:
> >   $ (export SSL_SESSCACHE=redis:localhost:6379; ./t/TEST -sslproto TLSv1.2
> > -defines TEST_SSL_SESSCACHE t/ssl)
>
> There was a thread on this discussing whether apr_pool_find() was really 
> safe...

Yeah, I saw it after writing this message.

>
> I think that's the right setup, but it did not *reliably* fail just by
> running t/TEST alone.  IIRC it did reliably fail by starting the server
> as in your command above, and then running "ab" against the server:
>
>   ab -qd -n 4000 -c 20 -f TLS1.2 https://localhost:8532/
>
> and https://github.com/apache/httpd/pull/140 showed this failure was
> specific to pool-debug.  I could reliably reproduce it locally as well.

I will try this.

I think that apr-1.7.0 and apr-util-1.6.1 are missing r1481186 and
r1822315 respectively. Both fixed quite some APR_POOL_DEBUG
correctness according to my late ASAN testing.
They were backported already, but there was no apr[-util] releases since then.

I'll try running ab with and without them, and see how it goes..
Also, RĂ¼diger (in some thread) proposed to lock pool_destroy_debug()
like it's done for pool_clear_debug() already, that looks interesting
too.

>
> > Since session caching is not a failure point in mod_ssl, I also verified
> > with redis up or down (and checked traffic with tcpdump), no luck either.
> > Does it happen only with socache_redis?
> > These seem to be the two threads racing:
>
> I don't think it is specific to redis, there was a similar failure in:
> https://travis-ci.org/github/apache/httpd/jobs/723103332 which used
> memcache for example.
>
> That said it's interesting and maybe significant if it doesn't fail with
> shmcb?

Let's see, thanks Joe.


Regards;
Yann.

Reply via email to