=head1 SUPPORT

=over 3

=item MAIL LIST

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

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

I<modperl-subscribe@perl.apache.org>

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

I<announce-subscribe@perl.apache.org>

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

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

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


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

=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 <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 
C<$SIG{USR1}> handler in your code, like so:

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

While the process is spinning, send it a I<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.

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

=back