=head1 NAME Getting Help =head1 Description If your question isn't answered by reading this guide, check this section for information on how to get help on mod_perl, Apache, or other topics discussed here. =head1 READ ME FIRST If, after reading this guide, the L and the L listed on this site, you still don't have the answers, please ask for help on the L. But please, first try to browse the L. Most of the time you will find the answers to your questions by searching the archive, since it is very likely that someone else has already encountered the same problem and found a solution for it. If you ignore this advice, you should not be surprised if your question is left unanswered -- it bores people to answer the same question again and again. This does not mean that you should avoid asking questions, but you should not abuse the available help and you should I before you call for I. (Remember the fable of the shepherd boy and the wolves). Another possibilty is to look in the general L section of this site for a commercial training or consulting company. =head2 Please Ask Only Questions Related to mod_perl If you have general Apache questions, please refer to: http://httpd.apache.org/lists.html. If you have general Perl questions, please refer to: http://lists.perl.org/. For other remotely related to mod_perl questions see the references to L. Finally, if you are posting to the list for the first time, please refer to the mod_perl mailing lists' L. =head1 How to Report Problems Make sure to include a good subject like explaining the problem in a few words. Also please mention that this a problem with mod_perl 1.0 (since now we have mod_perl 2.0 too). Here is an example of a good subject: Subject: [mp1] response handler randomly segfaults B to understand is that you should try hard to provide B the information that may assist to understand and reproduce the problem. When you prepare a bug report, put yourself in the position of a person who is going to try to help you, realizing that a guess-work on behalf of that helpful person, more often doesn't work than it does. Unfortunately most people don't realize that, and it takes several emails to squeeze the needed details from the person reporting the bug, a process which may drag for days. Always send the following details: =over =item * Anything in the I file that looks suspicious and possibly related to the problem. =item * Output of C =item * Version of mod_perl (hint: it's logged into the error_log file when the server has just started) =item * Version of apache (hint: it's logged into the error_log file when the server has just started) =item * Options given to mod_perl's Makefile.PL while building it. If you are using a pre-compiled binary (e.g., rpm), find the source package that was used to build this binary and retrieve this information from there. =item * Server configuration details (that's the relevant parts of your I, usually just the relevant mod_perl configuration sections). =item * Relevant sections of your C (make test's is: t/logs/error_log) =item * If some other code doesn't work, minimize that code to a minimal size while it reproduces the problem and attach it to the report. =item * If you build from source, make sure that C passes 100%. If C fails, run the failing tests L and attach the output of the run and the relevant sections of your C to the report. =back If this is a script which doesn't use mod_perl api, try to test under mod_cgi if applicable You should try to isolate the problem and send the smallest possible code snippet, that reproduces the problem. Remember, that if we cannot reproduce the problem, we might not be able to solve it. To further increase the chances that bugs your code exposes will be investigated, try using C to create a self-contained environment that core developers can use to easily reproduce your bug. To get you started, an C bug skeleton has been created: http://perl.apache.org/~geoff/bug-reporting-skeleton-mp1.tar.gz Detailed instructions are contained within the C. =over =item Getting the Backtrace From Core Dumps If you get a I file dump (I), please send a backtrace if possible. Before you try to produce it, re-build mod_perl with: panic% perl Makefile.PL PERL_DEBUG=1 which will: =over =item * add C<-g> to C =item * turn on C =item * set C (additional checks during Perl cleanup) =item * link against I if it exists =back Here is a summary of 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 So you go to the mod_perl source directory, create an empty I file, and start gdb with a path to the httpd binary, which is at least located in the Apache source tree after you built it. (Of course replace I with real version numbers). Next step is to start the httpd from within gdb and issue a request, which causes a core dump. when the code has died with SEGV sygnal, run I to get the backtrace. Alternatively you can also attach to an already running process like so: % gdb httpd If the dump is happening in I you have to rebuild Perl with C<-DDEBUGGING> enabled. A quick way to this is to go to your Perl source tree and run these commands: % rm *.[oa] % make LIBPERL=libperld.a % cp libperld.a $Config{archlibexp}/CORE where C<$Config{archlibexp}> is: % perl -V:archlibexp If the trace includes Apache calls and you see no arguments, you need to rebuild Apache with I<--without-execstrip>. If building a static mod_perl, you need to rebuild it with: % perl Makefile.PL ... APACI_ARGS='--without-execstrip' =item Spinning Processes The gdb attaching to the live process approach is helpful when debugging a I process. You can also get a Perl stacktrace of a I process by install a C<$SIG{USR1}> handler in your code: use Carp (); $SIG{USR1} = \&Carp::confess; While the process is spinning, send it a I signal: % kill -USR1 and the Perl stack trace will be printed. alternatively 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 After loading the special macros file (I<.gdbinit>) you can use the I gdb macro to figure out the file and line number the code stuck in. =back Finally send all these details to the modperl mailing list. =head1 Help on Related Topics When developing with mod_perl, you often find yourself having questions regarding other projects and topics like Apache, Perl, SQL, etc. L will help you find the right resource where you can find the answers to your questions. =head1 Maintainers Maintainer is the person(s) you should contact with updates, corrections and patches. =over =item * Stas Bekman [http://stason.org/] =back =head1 Authors =over =item * Stas Bekman [http://stason.org/] =back Only the major authors are listed above. For contributors see the Changes file. =cut