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 nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
