On Mon, Nov 23, 2020 at 2:33 PM Joe Orton <jor...@redhat.com> wrote:
>
> On Mon, Nov 23, 2020 at 01:24:39PM +0100, Yann Ylavic wrote:
> > --- srclib/apr-trunk/memory/unix/apr_pools.c (revision 1883742)
> > +++ srclib/apr-trunk/memory/unix/apr_pools.c (working copy)
> > @@ -1951,10 +1951,8 @@ APR_DECLARE(void) apr_pool_clear_debug(apr_pool_t
> >
> > static void pool_destroy_debug(apr_pool_t *pool, const char *file_line)
> > {
> > - apr_pool_check_lifetime(pool);
> > + apr_pool_clear_debug(pool, file_line);
> >
> > - pool_clear_debug(pool, file_line);
> > -
> > #if (APR_POOL_DEBUG & APR_POOL_DEBUG_VERBOSE)
> > apr_pool_log_event(pool, "DESTROY", file_line, 1);
> > #endif /* (APR_POOL_DEBUG & APR_POOL_DEBUG_VERBOSE) */):
> > --
> >
> > No more use-after-free, while without this patch there are many ones
> > (like in the attached ASAN report).
> > Note: pool_clear_debug is not mutex protected, while apr_pool_clear_debug
> > is.
>
> Nice work!Thanks, most credits to Rüdiger who suggested it! > > > Could we run APR_POOL_DEBUG test --with-inclued-apr (only) on travis, > > or fetching the sources causes issues still? > > Do you mean a different APR/APR-util tag/branch than 1.7.0/1.6.1? The > only restriction is that we can't test LDAP/pool-debug (usefully) if > building against APR trunk. We can switch to building against 1.7.x > branches, it works but adds a few minutes to the build time because we > can't cache the installs in that specific case. Yes apr-1.7.x and apr-util-1.7.x would be nice since we can CTR there quite easily and verify our fixes. > > BTW do you have an idiots guide to building/testing httpd with ASAN? We > could add that to travis too. Attached is my config.nice, I'm using ASAN from gcc-9 because gcc-10's is buggy for me (it somehow strips the link with libcrypt.so, without failing the build, and then crashes in apr_password_validate() when crypt_r() is called at a NULL address..). Then I run the perl test framework like this: $ (ulimit -c unlimited; export LSAN_OPTIONS=halt_on_error=1:disable_coredump=0:unmap_shadow_on_exit=1; ./t/TEST) Although the above LSAN_OPTIONS options are supposed to coredump whenever libasan detects something, it does not work for me (possibly has something to do with ASAN and httpd competing SEGV handlers..). The CFLAGS's -fsanitize-recover=address in addition to -fsanitize=address was an attempt to get coredumps too, not it's needed for the ci. Anyway, by default ASAN puts its reports on stderr, so I filter afterward with: $ grep -v "^\[" t/logs/error_log |less I think adding ":log_path=/path/to/asan/report.txt" to LSAN_OPTIONS could make it log wherever we want too (never tried though..). I wish I could make ASAN dump cores to be able to see all the threads when an issue occurs (and have a wider picture), because ASAN reports show only the two threads concerned by the faulty address. No luck with that on my machine so far, but it can very well be a local issue only. The two threads were enough for me to figure out so far.. Hth; Yann.
config.nice
Description: Binary data
