Bug#711213: Bug#711167: libapache2-mod-perl2: FTBFS on ia64: test suite failed to start server

[Niko Tyni]

On Fri, Jun 07, 2013 at 02:23:43PM +0300, Niko Tyni wrote:

> I can reproduce the SIGSEGV at the end of the main test suite (#711213)
> on amd64.  The armel problem might well be related, as the log ends at
> the same point.
> 
> My easiest recipe is
>    APACHE_TEST_EXTRA_ARGS="-httpd_conf /home/niko/apache2.conf" make run_tests TEST_FILES=t/user/rewrite.t
> where apache2.conf is like the one attached. 
> 
> It doesn't matter which tests get run; I managed to trigger it with no
> tests at all by just running apache2 manually and then killing it with
> SIGTERM. 
> 
> That means it looks like an apache2 bug. I haven't had the time to
> bisect the generated real apache2 config file further to get a minimal
> test case for the apache2 maintainers.

I'm somewhat further now: what happens is that register_auth_provider()
in modperl_util.c calls 
 apr_pool_pre_cleanup_register(pool, NULL, cleanup_perl_global_providers);
once in the parent process, then another time in a child. For some
reason that I do not understand yet, the cleanup_perl_global_providers()
function resides at a different memory location (with a 0x2c000 offset
or so) on the second time. The first location has at that point become
an invalid memory address, resulting in a SIGSEGV when libapr calls the
registered cleanup functions and jumps into the old location.

The perl module seems to get unloaded and loaded several times, but the
location of cleanup_perl_global_providers() seems to stay the same in
the parent process but differ in the child process. Perhaps a (re)load
occurring right after a fork() can make the memory layout differ?

I see this with both mpm_worker and mpm_prefork. It's something of a
heisenbug; I had to give up bisecting the config file when very unrelated
small changes would make it go away. Running apache2 under gdb or limiting
the stack size in any way also hides it here, as does recompiling apache2
(but not apr or mod_perl itself.) This makes proper instrumentation on
apache2 itself rather hard...

Will keep on glaring as time permits.
-- 
Niko Tyni   ntyni at debian.org