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:

Thanks to Ken Williams:

 http://forum.swarthmore.edu/epigone/modperl

Thanks to James Cooper:

 http://outside.organic.com/mail-archives/modperl/

Thanks to Hank Leininger:

 http://www.progressive-comp.com/Lists/?l=apache-modperl&r=1#apache-modperl

Thanks to FindMail:

 http://www.findmail.com/listsaver/modperl/

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 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.