=head1 SUPPORT =over 3 =item MAIL LIST For comments, questions, bug-reports, announcements, etc., send mail to I. To subscribe to this list (which you must do to send mail to the list), send a mail message to I We also have a mailing list just for announcements. Subscribe by sending a message to I Discussions about the perl.apache.org website and general mod_perl advocacy should go to the I mailing list. Subscribe by sending mail to I The HTML::Embperl mailing list is at I. Subscribe by (you properly got the idea by now) sending mail to I. All CVS commit messages goes to the I list. Embperl CVS messages goes to I. =item MAIL LIST ARCHIVES There are several modperl list archives, choose your favorite: http://perl.apache.org/maillist/modperl.html#Searchable_Archives =back =head1 REPORTING PROBLEMS =over 3 =item HOMEWORK Make sure you've done your homework before reporting a problem. Check the mail archive, read cgi_to_mod_perl.pod, the guide, the FAQ and other pod documents in the distribution. =item HOW When debugging, always start httpd with the C<-X> switch so only one process is started. Always check the error_log. =item WHERE Please send mail to modperl@perl.apache.org =item WHAT Always include this information: Output of C Version of mod_perl Version of apache Options given to mod_perl's Makefile.PL Server configuration details Relevant sections of your ErrorLog (make test's is: t/logs/error_log) If 'make test' fails, the output of 'make test TEST_VERBOSE=1' Depending on the nature of your problem, you may also be asked: -Does 'make test' pass 100%? -Does your script still work under CGI? -Do you have a *small* test script that illustrates the problem? -Can you get a backtrace (if httpd is dumping core)? =item CORE DUMPS If you get a core dump, please send a backtrace if possible. Before you try, build mod_perl with perl Makefile.PL PERL_DEBUG=1 which will: -add `-g' to EXTRA_CFLAGS -turn on PERL_TRACE -set PERL_DESTRUCT_LEVEL=2 (additional checks during Perl cleanup) -link against libperld if it exists Here's how to get a backtrace: % cd mod_perl-x.xx % touch t/conf/srm.conf % gdb ../apache_x.xx/src/httpd (gdb) run -X -f `pwd`/t/conf/httpd.conf -d `pwd`/t [now make request that causes core dump] (gdb) bt You can also attach to an already running process like so: % gdb httpd This attach approach is helpful when debugging a "spinning" process. You can also get a Perl stacktrace of a "spinning" process by install a C<$SIG{USR1}> handler in your code, like so: $SIG{USR1} = \&Carp::confess While the process is spinning, send it a I signal: % kill -USR1 Sometimes gdb can make heads or tails of the core file, try this: % gdb -core core or % gdb httpd core If the dump is happening in libperl a -DDEBUGGING enabled libperl would help show us what's really happening. Go to your Perl source tree: % rm *.[oa] % make LIBPERL=libperld.a % cp libperld.a $Config{archlibexp}/CORE $Config{archlibexp} is: % perl -V:archlibexp Rebuild httpd/mod_perl with PERL_DEBUG=1, let's see a new backtrace. If you get a segfault but no core file gets dumped and you cannot reproduce the segfault on will, you have to make sure that your environment is set to allow a core file to be dumped. Change the script that starts the server to do (in bash): ulimit -c unlimited before the code that starts the server. Alternatively you can execute this command from the shell and then start the server from the same shell. Now you should be able to get the core dumped. Of course the directory the server is running in (usually as defined by ServerRoot) should be writable as well. =item SPINNING PROCESSES If a process is spinning (seemingly stuck in an endless loop, eating up all cpu), you can use gdb to find which Perl code is causing the spin: % gdb httpd (gdb) where (gdb) source mod_perl-x.xx/.gdbinit (gdb) curinfo =back