cvs commit: modperl SUPPORT
stas2002/08/21 23:51:45 Modified:.SUPPORT Log: update the mail list archive URL Revision ChangesPath 1.19 +1 -1 modperl/SUPPORT Index: SUPPORT === RCS file: /home/cvs/modperl/SUPPORT,v retrieving revision 1.18 retrieving revision 1.19 diff -u -r1.18 -r1.19 --- SUPPORT 25 Mar 2002 02:57:59 - 1.18 +++ SUPPORT 22 Aug 2002 06:51:44 - 1.19 @@ -34,7 +34,7 @@ There are several modperl list archives, choose your favorite: -http://perl.apache.org/#maillists +http://perl.apache.org/maillist/modperl.html#Searchable_Archives =back
cvs commit: modperl SUPPORT
stas01/09/19 10:03:17 Modified:.SUPPORT Log: setting env for getting the core file dumped note Revision ChangesPath 1.17 +13 -0 modperl/SUPPORT Index: SUPPORT === RCS file: /home/cvs/modperl/SUPPORT,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- SUPPORT 2000/06/09 17:15:59 1.16 +++ SUPPORT 2001/09/19 17:03:17 1.17 @@ -143,6 +143,19 @@ 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
cvs commit: modperl SUPPORT
dougm 00/06/09 10:16:01 Modified:.SUPPORT Log: support stuff Revision ChangesPath 1.16 +5 -18 modperl/SUPPORT Index: SUPPORT === RCS file: /home/cvs/modperl/SUPPORT,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- SUPPORT 2000/06/02 17:06:38 1.15 +++ SUPPORT 2000/06/09 17:15:59 1.16 @@ -34,21 +34,7 @@ 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/ +http://perl.apache.org/#maillists =back @@ -59,8 +45,8 @@ =item 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. +Check the mail archive, read cgi_to_mod_perl.pod, the guide, the FAQ +and other pod documents in the distribution. =item HOW @@ -165,7 +151,8 @@ spin: % gdb httpd -(gdb) source modperl_x.xx/.gdbinit +(gdb) where +(gdb) source mod_perl-x.xx/.gdbinit (gdb) curinfo =back
cvs commit: modperl SUPPORT
cholet 00/06/02 10:06:39 Modified:.SUPPORT Log: add Doug's snippet about spinning processes Revision ChangesPath 1.15 +11 -0 modperl/SUPPORT Index: SUPPORT === RCS file: /home/cvs/modperl/SUPPORT,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- SUPPORT 2000/03/03 00:30:52 1.14 +++ SUPPORT 2000/06/02 17:06:38 1.15 @@ -157,5 +157,16 @@ Rebuild httpd/mod_perl with PERL_DEBUG=1, let's see a new backtrace. + +=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 +(gdb) source modperl_x.xx/.gdbinit +(gdb) curinfo + =back
