Last month, before moving to Melbourne, where I am now, to work in the Opera Australia office for a few months, I had to setup a laptop for all the development work I normally do. So I chose Ubuntu 10.10 amd64. I have to say I'm quite happy with it. Everything works out of the box for me, including a Quickcam 9000 USB camera I used to shoot this poor time-lapse video from my new office window. Woot!
Anyway, the development environment for one particular project consists of Apache and mod_perl. So I setup the usual list of dependencies, but when I tried to start Apache to run the test suite, it would always stop right away with a segmentation fault.
Didn't really dig into the problem. Just strace
d the apache process, and that's what I got:
[apache starts up, reads a bunch of Perl modules, and opens the access
log...]
...
brk(0x7f342adbd000) = 0x7f342adbd000
...
...
brk(0x7f342adde000) = 0x7f342adde000
brk(0x7f342adff000) = 0x7f342adff000
brk(0x7f342ae20000) = 0x7f342ae20000
brk(0x7f342ae41000) = 0x7f342ae41000
stat("/usr/lib/perl5/auto/DBI/DESTROY.al", 0x7f341e8459b0) = -1 ENOENT (No
such file or directory)
stat("/home/cosimo/src/auth-svn/lib/auto/DBI/DESTROY.al", 0x7fffc4e2d520)
= -1 ENOENT (No such file or directory)
stat("/home/cosimo/src/myopera-trunk/lib/auto/DBI/DESTROY.al",
0x7fffc4e2d520) = -1 ENOENT (No such file or directory)
stat("/etc/perl/auto/DBI/DESTROY.al", 0x7fffc4e2d520) = -1 ENOENT (No such
file or directory)
stat("/usr/local/lib/perl/5.10.1/auto/DBI/DESTROY.al", 0x7fffc4e2d520) =
-1 ENOENT (No such file or directory)
stat("/usr/local/share/perl/5.10.1/auto/DBI/DESTROY.al", 0x7fffc4e2d520) =
-1 ENOENT (No such file or directory)
stat("/usr/lib/perl5/auto/DBI/DESTROY.al", 0x7fffc4e2d520) = -1 ENOENT (No
such file or directory)
stat("/usr/share/perl5/auto/DBI/DESTROY.al", 0x7fffc4e2d520) = -1 ENOENT
(No such file or directory)
stat("/usr/lib/perl/5.10/auto/DBI/DESTROY.al", 0x7fffc4e2d520) = -1 ENOENT
(No such file or directory)
stat("/usr/share/perl/5.10/auto/DBI/DESTROY.al", 0x7fffc4e2d520) = -1
ENOENT (No such file or directory)
stat("/usr/local/lib/site_perl/auto/DBI/DESTROY.al", 0x7fffc4e2d520) = -1
ENOENT (No such file or directory)
stat("./auto/DBI/DESTROY.al", 0x7fffc4e2d520) = -1 ENOENT (No such file or
directory)
stat("/var/tmp/test_cosimo_22931/auto/DBI/DESTROY.al", 0x7fffc4e2d520) =
-1 ENOENT (No such file or directory)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
I thought it would be wiser to ask for advice on the DBI and mod_perl mailing lists. Tim Bunce suggested to try and get a stack trace of Apache. Why didn't I think of that in the first place? A few days later, I got my stack trace:
# gdb -c ./core /usr/sbin/apache2
...
Reading symbols from ...
...
Core was generated by `/usr/sbin/apache2 -d /var/tmp/test_cosimo_9727 -k
start -C User cosimo -C Group ...'.
Program terminated with signal 11, Segmentation fault.
#0 0x00007fdaedfed858 in XS_Class__XSAccessor_END ()
from /usr/lib/perl5/auto/Class/XSAccessor/XSAccessor.so
(gdb) backtrace
#0 0x00007fdaedfed858 in XS_Class__XSAccessor_END ()
from /usr/lib/perl5/auto/Class/XSAccessor/XSAccessor.so
#1 0x00007fdaf83cf845 in Perl_pp_entersub () from /usr/lib/libperl.so.5.10
#2 0x00007fdaf83752c6 in Perl_call_sv () from /usr/lib/libperl.so.5.10
#3 0x00007fdaf86ad40b in modperl_perl_call_list ()
from /usr/lib/apache2/modules/mod_perl.so
#4 0x00007fdaf86b5786 in modperl_perl_destruct ()
from /usr/lib/apache2/modules/mod_perl.so
#5 0x00007fdaf86a6256 in modperl_interp_destroy ()
from /usr/lib/apache2/modules/mod_perl.so
#6 0x00007fdaf86a6715 in modperl_tipool_destroy ()
from /usr/lib/apache2/modules/mod_perl.so
#7 0x00007fdaf86a62b2 in modperl_interp_pool_destroy ()
from /usr/lib/apache2/modules/mod_perl.so
#8 0x00007fdaf98fd4e3 in ?? () from /usr/lib/libapr-1.so.0
#9 0x00007fdaf98fc3b1 in apr_pool_destroy () from /usr/lib/libapr-1.so.0
#10 0x00007fdaf98fc27f in apr_pool_clear () from /usr/lib/libapr-1.so.0
#11 0x00007fdafa1b960d in main (argc=11, argv=0x7fff93b50ef8)
at /build/buildd/apache2-2.2.16/server/main.c:692
Even if you don't know anything about stack traces, this output gently points to Class::XSAccessor. Perrin Harkins on the mod_perl list suggested to update Class::XSAccessor to the latest CPAN version, since its changelog mentioned some segmentation faults fixed in 0.10.
And that did it. No more segfaults on Ubuntu 10.10. Solution: upgrade Class::XSAccessor to 0.10+. Thanks to Class::XSAccessor maintainer(s)!