SUPPORT

MAIL LIST

For comments, questions, bug-reports, announcements, etc., send mail to modperl@apache.org.

To subscribe to this list (which you must do to send mail to the list), send a mail message to

modperl-subscribe@apache.org

We also have a mailing list just for announcements. Subscribe by sending a message to

announce-subscribe@perl.apache.org

Discussions about the perl.apache.org website and general mod_perl advocacy should go to the advocacy@perl.apache.org mailing list. Subscribe by sending mail to advocacy-subscribe@perl.apache.org

The HTML::Embperl mailing list is at embperl@perl.apache.org. Subscribe by (you properly got the idea by now) sending mail to embperl-subscribe@perl.apache.org.

All CVS commit messages goes to the modperl-cvs@apache.org list. Embperl CVS messages goes to embperl-cvs@perl.apache.org.

MAIL LIST ARCHIVES

There are several modperl list archives, choose your favorite:

http://perl.apache.org/#maillists

REPORTING PROBLEMS

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.

HOW

When debugging, always start httpd with the -X switch so only one process is started.

Always check the error_log.

WHERE

Please send mail to modperl@apache.org

WHAT

Always include this information:

Output of perl -V

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)?

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 <process id number>

This attach approach is helpful when debugging a "spinning" process. You can also get a Perl stacktrace of a "spinning" process by install a $SIG{USR1} handler in your code, like so:

$SIG{USR1} = \&Carp::confess

While the process is spinning, send it a USR1 signal:

% kill -USR1 <process id number>

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.

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 <pid of spinning process> (gdb) where (gdb) source mod_perl-x.xx/.gdbinit (gdb) curinfo