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.