23.1 How to Report Problems

When reporting a problem to the mod_perl mailing list, always send these details:

• Anything in the error_log file that looks suspicious and possibly related to the problem

• Output of perl -V

• Version of mod_perl

• Version of Apache

• Options given to mod_perl's Makefile.PL file

• Server configuration details

• If make test fails, the output of make test TEST_VERBOSE=1

Also check whether:

• make test passes 100%

• The script works under mod_cgi, if applicable

You should try to isolate the problem and send the smallest possible code snippet that reproduces the problem.

23.1.1 Getting the Backtrace from Core Dumps

If you get a core dump (segmentation fault), send a backtrace if possible. Before you try to produce it, rebuild mod_perl with:

panic% 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

You can read a full explanation in Chapter 21, but here is a summary of how to get a backtrace:

panic% cd mod_perl-1.xx
panic% gdb ../apache_1.3.xx/src/httpd
(gdb) run -X -f `pwd`/t/conf/httpd.conf -d `pwd`/t
[now make request that causes core dump]
(gdb) bt

In English: cd to the mod_perl source directory and start gdb with a path to the httpd binary, which is located in the Apache source tree. (Of course, replace x with real version numbers.) Next, start the httpd process from within gdb and issue a request that causes a core dump. When the code has died with the SIGSEGV signal, run bt to get the backtrace.

Alternatively, you can also attach to an already running process like so:

panic% gdb httpd <process id number>

If the dump is happening in libperl, you have to rebuild Perl with -DDEBUGGING enabled during the ./Configure stage. A quick way to this is to go to your Perl source tree and run these commands:

panic% rm *.[oa]
panic% make LIBPERL=libperld.a
panic% cp libperld.a $Config{archlibexp}/CORE

where $Config{archlibexp} is:

% perl -V:archlibexp

23.1.2 Spinning Processes

The gdb attaching to the live process approach is helpful when debugging a spinning process. You can also get a Perl stack trace of a spinning process by installing a $SIG{USR1} handler in your code:

use Carp ( );
$SIG{USR1} = \&Carp::confess;

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

panic% kill -USR1 <process id number>

and the Perl stack trace will be printed.

Alternatively, you can use gdb to find which Perl code is causing the spin:

panic% gdb httpd <pid of spinning process>
(gdb) where
(gdb) source mod_perl-x.xx/.gdbinit
(gdb) curinfo

After loading the special macros file (.gdbinit), you can use the curinfo gdb macro to figure out the file and line number in which the code stuck. Chapter 21 talks in more detail about tracing techniques.

Finally, send all these details to [email protected].