perl-docs-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From s...@apache.org
Subject svn commit: r106364 - /perl/modperl/docs/trunk/src/docs/2.0/devel/debug/c.pod /perl/modperl/docs/trunk/src/docs/2.0/user/help/help.pod
Date Wed, 24 Nov 2004 00:34:16 GMT
Author: stas
Date: Tue Nov 23 16:34:15 2004
New Revision: 106364

Modified:
   perl/modperl/docs/trunk/src/docs/2.0/devel/debug/c.pod
   perl/modperl/docs/trunk/src/docs/2.0/user/help/help.pod
Log:
rewrite/update the dealing with segfaults documents


Modified: perl/modperl/docs/trunk/src/docs/2.0/devel/debug/c.pod
Url: http://svn.apache.org/viewcvs/perl/modperl/docs/trunk/src/docs/2.0/devel/debug/c.pod?view=diff&rev=106364&p1=perl/modperl/docs/trunk/src/docs/2.0/devel/debug/c.pod&r1=106363&p2=perl/modperl/docs/trunk/src/docs/2.0/devel/debug/c.pod&r2=106364
==============================================================================
--- perl/modperl/docs/trunk/src/docs/2.0/devel/debug/c.pod	(original)
+++ perl/modperl/docs/trunk/src/docs/2.0/devel/debug/c.pod	Tue Nov 23 16:34:15 2004
@@ -13,9 +13,15 @@
 L<mod_perl-specific functionality
 flow|docs::2.0::devel::core::mod_perl_specific>.
 
+
+
+
+
+
 =head1 Debug notes
 
-META: needs more organization
+META: needs more organization (if you grok any of the following,
+patches are welcome)
 
 META: there is a new directive CoreDumpDirectory in 2.0.45, need to
 check whether we should mention it.
@@ -44,6 +50,8 @@
 
 
 
+
+
 =head2 Entering Single Server Mode
 
 Most of the time, when debugging Apache or mod_perl, one needs to
@@ -56,6 +64,8 @@
 
 
 
+
+
 =head2 Setting gdb Breakpoints with mod_perl Built as DSO
 
 If mod_perl is built as a DSO module, you cannot set the breakpoint in
@@ -100,6 +110,13 @@
   % gdb /home/stas/httpd-2.0/bin/httpd -command \
   `pwd`/t/.gdb-jump-to-init
 
+
+
+
+
+
+
+
 =head2 Starting the Server Fast under gdb
 
 When the server is started under gdb, it first loads the symbol tables
@@ -254,6 +271,11 @@
 which will block till the server starts responding, and only then will
 try to run the test.
 
+
+
+
+
+
 =head2 Precooked gdb Startup Scripts
 
 Here are a few startup scripts you can use with gdb to accomplish one
@@ -313,199 +335,155 @@
 =back
 
 
-=head1 Analyzing Dumped Core Files
 
-META: need to review (unfinished)
+
+
+
+
+=head1 Analyzing Dumped Core Files
 
 When your application dies with the I<Segmentation fault> error (which
-generates a C<SIGSEGV> signal) and optionally generates a I<core> file
-you can use C<gdb> or a similar debugger to find out what caused the
-I<Segmentation fault> (or I<segfault> as we often call it).
+is generated by the C<SIGSEGV> signal) and optionally generates a
+F<core> file you can use C<gdb> or a similar debugger to find out what
+caused the I<Segmentation fault> (or a I<segfault> as we often call
+it).
+
+
+
+
 
 =head2 Getting Ready to Debug
 
-In order to debug the I<core> file we may need to recompile Perl and
-mod_perl with debugging symbols inside. Usually you have to recompile
-only mod_perl, but if the I<core> dump happens in the I<libmodperl.so>
-library and you want to see the whole backtrace, you probably want to
-recompile Perl as well.
-
-Recompile Perl with I<-DDEBUGGING> during the ./Configure stage (or
-even better with I<-Doptimize="-g"> which in addition to adding the
-C<-DDEBUGGING> option, adds the I<-g> options which allows you to
-debug the Perl interpreter itself).
+In order to debug the F<core> file you may need to recompile Perl and
+mod_perl with debugging symbols. Usually you have to recompile only
+mod_perl, but if the F<core> dump happens in the I<libperl.so> library
+and you want to see the whole backtrace, you need to recompile Perl as
+well. It may also occur inside httpd or 3rd party module, in which
+case you will need to recompile those. The following notes should help
+to accomplish the right thing:
+
+=over
 
-After recompiling Perl, recompile mod_perl with C<MP_DEBUG=1> during
-the I<Makefile.PL> stage.
+=item * mod_perl
+
+rebuild mod_perl with C<MP_DEBUG=1>.
+
+  % perl Makefile.PL MP_DEBUG=1 ...
+  % make && make test && make install
 
 Building mod_perl with C<PERL_DEBUG=1> will:
 
 =over
 
-=item 1 
+=item 1
 
-add `-g' to EXTRA_CFLAGS
+add C<-g> to C<EXTRA_CFLAGS>
 
-=item 1 
+=item 1
 
-turn on MP_TRACE (tracing)
+turn on C<MP_TRACE> (tracing)
 
-=item 1 
+=item 1
 
-Set PERL_DESTRUCT_LEVEL=2
+Set C<PERL_DESTRUCT_LEVEL=2>
 
-=item 1 
+=item 1
 
-Link against C<libperld> if -e $Config{archlibexp}/CORE/libperld$Config{lib_ext}
+Link against F<libperld.so> if
+F<$Config{archlibexp}/CORE/libperld$Config{lib_ext}> exists.
 
 =back
 
-If you build a static mod_perl, remember that during I<make install>
-Apache strips all the debugging symbols.  To prevent this you should
-use the Apache I<--without-execstrip> C<./configure> option. So if you
-configure Apache via mod_perl, you should do:
-
-  panic% perl Makefile.PL USE_APACI=1 \
-    APACI_ARGS='--without-execstrip' [other options]
-
-Alternatively you can copy the unstripped binary manually. For example
-we did this to give us an Apache binary called C<httpd_perl> which
-contains debugging symbols:
+=item * httpd
 
-  panic# cp httpd-2.x/httpd /home/httpd/httpd_perl/bin/httpd_perl
+If the segfault happens inside I<ap_> or I<apr_> calls, rebuild httpd
+with C<--enable-maintainer-mode>:
 
-Now the software is ready for a proper debug.
+  % ./configure --enable-maintainer-mode ...
+  % make && make install
 
-=head2 Creating a Faulty Package
+=item * perl
 
-META: no longer need to create the package, use C<Debug::DumpCore>
-from CPAN. Need to adjust the rest of the document to use it.
+If the segfault happens inside I<Perl_> calls, rebuild perl with
+C<-Doptimize='-g'>:
 
-Next stage is to create a package that aborts abnormally with the
-I<Segmentation fault> error. We will write faulty code on purpose,
-so you will be able to reproduce the problem and exercise the
-debugging technique explained here. Of course in a real case you
-will have some real bug to debug, so in that case you may want to
-skip this stage of writing a program with a deliberate bug.
-
-We will use the C<Inline.pm> module to embed some code written in C
-into our Perl script. The faulty function that we will add is this:
-
-  void segv() {
-      int *p;
-      p = NULL;
-      printf("%d", *p); /* cause a segfault */
-  }
-
-For those of you not familiar with C programming, I<p> is a pointer to
-a segment of memory.  Setting it to C<NULL> ensures that we try to
-read from a segment of memory to which the operating system does not
-allow us access, so of course dereferencing C<NULL> pointer causes a
-segmentation fault.  And that's what we want.
-
-So let's create the C<Bad::Segv> package. The name I<Segv> comes from
-the C<SIGSEGV> (segmentation violation signal) that is generated when
-the I<Segmentation fault> occurs.
-
-First we create the installation sources:
-
-  panic% h2xs -n Bad::Segv -A -O -X
-  Writing Bad/Segv/Segv.pm
-  Writing Bad/Segv/Makefile.PL
-  Writing Bad/Segv/test.pl
-  Writing Bad/Segv/Changes
-  Writing Bad/Segv/MANIFEST
+  % ./Configure -Doptimize='-g' ...
+  % make && make test && make install
 
-Now we modify the I<Segv.pm> file to include the C code. Afterwards
-it looks like this:
+Remember to recompile mod_perl if you've recompiled perl.
 
-  package Bad::Segv;
-  
-  use strict;
-  BEGIN {
-      $Bad::Segv::VERSION = '0.01';
-  }
-  
-  use Inline C => <<'END_OF_C_CODE';
-    void segv() {
-        int *p;
-        p = NULL;
-        printf("%d", *p); /* cause a segfault */
-    }
-  
-  END_OF_C_CODE
-  
-  1;
+=item * 3rd party perl modules
 
-Finally we modify I<test.pl>:
+if the trace happens in one of the 3rd party perl modules, make sure
+to rebuild them, now that you've perl re-built with debugging
+flags. They will automatically pick the right compile flags from perl.
 
-  use Inline SITE_INSTALL;
-  
-  BEGIN { $| = 1; print "1..1\n"; }
-  END {print "not ok 1\n" unless $loaded;}
-  use Bad::Segv;
-  
-  $loaded = 1;
-  print "ok 1\n";
+=back
+
+Now the software is ready for a proper debug.
 
-Note that we don't test Bad::Segv::segv() in I<test.pl>, since this
-will abort the I<make test> stage abnormally, and we don't want this.
 
-Now we build and install the package:
 
-  panic% perl Makefile.PL
-  panic% make && make test
-  panic% su
-  panic# make install
 
-Running I<make test> is essential for C<Inline.pm> to prepare the binary
-object for the installation during I<make install>.
 
+=head2 Causing a SegFault
 
-META: stopped here!
+Most likely you already have the segfault situation, but sometimes you
+want to create one. For example sometimes you need to make sure that
+L<your system is configured to dump core
+files|/Getting_the_core_File_Dumped>.
 
-Now we can test the package:
+For that purpose you can use C<Debug::DumpCore> available from CPAN:
+http://search.cpan.org/dist/Debug-FaultAutoBT/
 
-  panic% ulimit -c unlimited
-  panic% perl -MBad::Segv -e 'Bad::Segv::segv()'
+  % perl -MDebug::DumpCore -eDebug::DumpCore::segv
   Segmentation fault (core dumped)
-  panic% ls -l core
-  -rw-------  1  stas stas 1359872  Feb 6  14:08 core
 
-Indeed, we can see that the I<core> file was dumped, which will be used
-to present the debug techniques.
+Notice that you could use Perl's C<CORE::dump> to achieve the same
+goal:
+
+  % perl -le 'dump'
+  Abort (core dumped)
+
+but the generated in that case backtrace is not very useful for
+learning purposes. If all you want to test is whether L<your system is
+configured to dump core files|/Getting_the_core_File_Dumped> then
+Perl's C<CORE::dump> will do just fine.
+
+
+
+
 
 =head2 Getting the core File Dumped
 
-Now let's get the I<core> file dumped from within the mod_perl
+Now let's get the F<core> file dumped from within the mod_perl
 server. Sometimes the program aborts abnormally via the SIGSEGV signal
-(I<Segmentation Fault>), but no I<core> file is dumped. And without
-the I<core> file it's hard to find the cause of the problem, unless
+(I<Segmentation Fault>), but no F<core> file is dumped. And without
+the F<core> file it's hard to find the cause of the problem, unless
 you run the program inside C<gdb> or another debugger in first
-place. In order to get the I<core> file, the application has to:
+place. In order to get the F<core> file, the application has to:
 
 =over
 
-=item *
+=item 1
 
 have the effective UID the same as real UID (the same goes for
 GID). Which is the case of mod_perl unless you modify these settings
 in the program.
 
-=item *
+=item 1
 
-be running from a directory which at the moment of the
-I<Segmentation fault> is writable by the process. Notice that the
-program might change its current directory during its run, so it's
-possible that the I<core> file will need to be dumped in a different
-directory from the one the program was started from. For example when
-mod_perl runs an C<Apache::Registry> script it changes its directory
-to the one in which the script source is located.
+be running from a directory which at the moment of the I<Segmentation
+fault> is writable by the process that received this signal. Notice
+that the program might change its current directory during its run, so
+it's possible that the F<core> file will need to be dumped in a
+different directory from the one the program was originally started
+from.
 
-=item *
+=item 1
 
 be started from a shell process with sufficient resource allocations
-for the I<core> file to be dumped. You can override the default
+for the F<core> file to be dumped. You can override the default
 setting from within a shell script if the process is not started
 manually. In addition you can use C<BSD::Resource> to manipulate the
 setting from within the code as well.
@@ -520,188 +498,263 @@
 
   panic% limit coredumpsize unlimited
 
-For example you can set an upper limit on the I<core> file size to 8MB
+For example you can set an upper limit on the F<core> file size to 8MB
 with:
 
   panic% ulimit -c 8388608
 
 So if the core file is bigger than 8MB it will be not created.
 
-=item *
+=item 1
 
 Of course you have to make sure that you have enough disk space to
-create a big core file (mod_perl I<core> files tend to be of a few
-MB in size).
+create a big core file (mod_perl F<core> files tend to be of a few MB
+in size).
 
 =back
 
 Note that when you are running the program under a debugger like
-C<gdb>, which traps the C<SIGSEGV> signal, the I<core> file will not
+C<gdb>, which traps the C<SIGSEGV> signal, the F<core> file will not
 be dumped. Instead it allows you to examine the program stack and
-other things without having the I<core> file.
+other things without having the F<core> file.
 
-So let's write a simple script that uses C<Bad::Segv>:
+So let's write a simple script that uses C<Debug::DumpCore>:
 
   core_dump.pl
   ------------
   use strict;
-  use Bad::Segv ();
-  use Cwd()
+  use warnings FATAL => 'all';
+  
+  use Apache::RequestRec ();
+  use Apache::RequestIO ();
+  use Debug::DumpCore ();
+  use Cwd;
   
   my $r = shift;
   $r->content_type('text/plain');
   
-  my $dir = getcwd;
-  $r->print("The core should be found at $dir/core\n");
-  Bad::Segv::segv();
-
-In this script we load the C<Bad::Segv> and C<Cwd> modules. After
-that we acquire the request object and send the HTTP header. Now we
-come to the real part--we get the current working directory, print out
-the location of the I<core> file that we are about to dump and finally
-we call Bad::Segv::segv() which dumps the I<core> file.
+  my $dir = getcwd();
+  $r->print("The core should be found at $dir/core.$$\n");
+  $r->rflush;
+  
+  Debug::DumpCore::segv();
+
+In this script we load the C<Apache::RequestRec>,
+C<Apache::RequestIO>, C<Debug::DumpCore> and C<Cwd> modules, then we
+acquire the Apache request object and set the HTTP response
+header. Now we come to the real part -- we get the current working
+directory, print out the location of the F<core> file that we are
+about to dump and finally we call C<Debug::DumpCore::segv()> which
+dumps the F<core> file.
 
-Before we run the script we make sure that the shell sets the I<core>
+Before we run the script we make sure that the shell sets the F<core>
 file size to be unlimited, start the server in single server mode as a
 non-root user and generate a request to the script:
 
-  panic% cd /home/httpd/httpd_perl/bin
+  panic% cd /home/httpd/bin
   panic% limit coredumpsize unlimited
-  panic% ./httpd_perl -X
+  panic% ./httpd -DONE_PROCESS -DNO_DETACH
       # issue a request here
   Segmentation fault (core dumped)
 
 Our browser prints out:
 
-  The core should be found at /home/httpd/perl/core
+  The core should be found at /home/httpd/bin/core.12345
 
-And indeed the core file appears where we were told it will (remember
-that C<Apache::Registry> scripts change their directory to the
-location of the script source):
+And indeed the core file appears where we were told it will be:
 
-  panic% ls -l /home/httpd/perl/core
-  -rw------- 1 stas httpd 3227648 Feb 7 18:53 /home/httpd/perl/core
+ panic% ls -l /home/httpd/bin/core.12345
+ -rw-------  1 stas stas 13758464 Nov 23 18:33 /home/httpd/bin/core.12345
 
-As you can see it's a 3MB I<core> file. Notice that mod_perl was
+As you can see it's about 14MB F<core> file. Notice that mod_perl was
 started as user I<stas>, which had write permission for directory
-I</home/httpd/perl>.
+I</home/httpd/bin>.
+
+Notice that on certain platforms you get no PID digits appended to the
+core file name, so sometimes, it'll be just F<core>.
+
+
+
+
+
 
 
 =head2 Analyzing the core File
 
 First we start C<gdb>:
 
-  panic% gdb /home/httpd/httpd_perl/bin/httpd_perl /home/httpd/perl/core
+  panic% gdb /home/httpd/bin/httpd /home/httpd/bin/core.12345
 
 with the location of the mod_perl executable and the core file as the
 arguments.
 
 To see the backtrace you run the I<where> or the I<bt> command:
 
-  (gdb) where
-  #0  0x4025ea08 in XS_Apache__Segv_segv ()
-     from /usr/lib/perl5/site_perl/5.6.0/i386-linux/auto/Bad/Segv_C_0_01_e6b5959d800f515de36a7e7eeab28b39/Segv_C_0_01_e6b5959d800f515de36a7e7eeab28b39.so
-  #1  0x40136528 in PL_curcopdb ()
-     from /usr/lib/perl5/5.6.0/i386-linux/CORE/libperl.so
+  (gdb) bt
+  #0  0x407ab26c in crash_now_for_real (
+      suicide_message=0x407ad300 "Cannot stand this life anymore")
+      at DumpCore.xs:10
+  #1  0x407ab293 in crash_now (
+      suicide_message=0x407ad300 "Cannot stand this life anymore",
+      attempt_num=42) at DumpCore.xs:17
+  #2  0x407ab39b in XS_Debug__DumpCore_segv (my_perl=0x86a9298, cv=0x8d36750)
+      at DumpCore.xs:26
+  #3  0x40540649 in Perl_pp_entersub () from .../libperl.so
+  ...
+  #7  0x404530cc in modperl_callback () from .../mod_perl.so
 
 Well, you can see the last commands, but our perl and mod_perl are
-probably without the debug symbols. So we recompile Perl and mod_perl
-with debug symbols as explained earlier in this chapter.
+probably without the debug symbols. This is not the kind of trace you
+should send as a part of your bug report, because a lot of important
+information that should aid resolve the reported problem is missing.
+
+Therefore the next step is to recompile Perl and mod_perl (and may be
+Apache) with debug symbols as L<explained
+earlier|Getting_Ready_to_Debug> in this chapter.
 
 Now when we repeat the process of starting the server, issuing a
 request and getting the core file, after which we run C<gdb> again
-against the executable and the dumped I<core> file.
+against the executable and the dumped F<core.6789> file.
 
-  panic% gdb /home/httpd/httpd_perl/bin/httpd_perl /home/httpd/perl/core
+  panic% gdb /home/httpd/bin/httpd /home/httpd/bin/core.6789
 
 Now we can see the whole backtrace:
 
   (gdb) bt
-  #0  0x40323a30 in segv () at Segv_C_0_01_e6b5959d800f515de36a7e7eeab28b39.xs:9
-  #1  0x40323af8 in XS_Apache__Segv_segv (cv=0x85f2b28)
-      at Segv_C_0_01_e6b5959d800f515de36a7e7eeab28b39.xs:24
-  #2  0x400fcbda in Perl_pp_entersub () at pp_hot.c:2615
-  #3  0x400f2c56 in Perl_runops_debug () at run.c:53
-  #4  0x4008b088 in S_call_body (myop=0xbffff788, is_eval=0) at perl.c:1796
-  #5  0x4008ac4f in perl_call_sv (sv=0x82fc2e4, flags=4) at perl.c:1714
-  #6  0x807350e in perl_call_handler ()
-  #7  0x80729cd in perl_run_stacked_handlers ()
-  #8  0x80701b4 in perl_handler ()
-  #9  0x809f409 in ap_invoke_handler ()
-  #10 0x80b3e8f in ap_some_auth_required ()
-  #11 0x80b3efa in ap_process_request ()
-  #12 0x80aae60 in ap_child_terminate ()
-  #13 0x80ab021 in ap_child_terminate ()
-  #14 0x80ab19c in ap_child_terminate ()
-  #15 0x80ab80c in ap_child_terminate ()
-  #16 0x80ac03c in main ()
-  #17 0x401b8cbe in __libc_start_main () from /lib/libc.so.6
-
-Reading the trace from bottom to top, we can see that it starts with Apache
-calls, followed by Perl syscalls. At the top we can see the segv()
-call which was the one that caused the Segmentation fault, we can also
-see that the faulty code was at line 9 of I<Segv.xs> file (with MD5
-signature of the code in the name of the file, because of the way
-C<Inline.pm> works). It's a little bit tricky with C<Inline.pm> since
-we have never created any I<.xs> files ourselves, (C<Inline.pm> does
-it behind the scenes). The solution in this case is to tell
-C<Inline.pm> not to cleanup the build directory, so we can see the
-created I<.xs> file.
-
-We go back to the directory with the source of C<Bad::Segv> and
-force the recompilation, while telling C<Inline.pm> not to cleanup
-after the build and to print a lot of other useful info:
-
-  panic# cd Bad/Segv
-  panic# perl -MInline=FORCE,NOCLEAN,INFO Segv.pm
-  Information about the processing of your Inline C code:
-  
-  Your module is already compiled. It is located at:
-  /home/httpd/perl/Bad/Segv/_Inline/lib/auto/Bad/Segv_C_0_01_e6b5959d800f515de36a7e7eeab28b39/Segv_C_0_01_e6b5959d800f515de36a7e7eeab28b39.so
-  
-  But the FORCE_BUILD option is set, so your code will be recompiled.
-  I'll use this build directory:
-  /home/httpd/perl/Bad/Segv/_Inline/build/Bad/Segv_C_0_01_e6b5959d800f515de36a7e7eeab28b39/
-  
-  and I'll install the executable as:
-  /home/httpd/perl/Bad/Segv/_Inline/lib/auto/Bad/Segv_C_0_01_e6b5959d800f515de36a7e7eeab28b39/Segv_C_0_01_e6b5959d800f515de36a7e7eeab28b39.so
-  
-  The following Inline C function(s) have been successfully bound to Perl:
-    void segv()
-
-It tells us that the code was already compiled, but since we have
-forced it to recompile we can look at the files after the build. So we
-go into the build directory reported by C<Inline.pm> and find the
-I<.xs> file there, where on line 9 we indeed find the faulty code:
-
-  9: printf("%d",*p); // cause a segfault
+  #0  0x407ab26c in crash_now_for_real (
+      suicide_message=0x407ad300 "Cannot stand this life anymore")
+      at DumpCore.xs:10
+  #1  0x407ab293 in crash_now (
+      suicide_message=0x407ad300 "Cannot stand this life anymore",
+      attempt_num=42) at DumpCore.xs:17
+  #2  0x407ab39b in XS_Debug__DumpCore_segv (my_perl=0x86a9298, cv=0x8d36750)
+      at DumpCore.xs:26
+  #3  0x40540649 in Perl_pp_entersub (my_perl=0x86a9298) at pp_hot.c:2890
+  #4  0x4051ca4d in Perl_runops_debug (my_perl=0x86a9298) at dump.c:1449
+  #5  0x404c1ea3 in S_call_body (my_perl=0x86a9298, myop=0xbfffed90, is_eval=0)
+      at perl.c:2298
+  #6  0x404c19cf in Perl_call_sv (my_perl=0x86a9298, sv=0x8cd0914, flags=4)
+      at perl.c:2216
+  #7  0x404530cc in modperl_callback (my_perl=0x86a9298, handler=0x81ba6d8,
+      p=0x8d16828, r=0x8d16860, s=0x813d238, args=0x8d018d8)
+      at modperl_callback.c:102
+  #8  0x404539ce in modperl_callback_run_handlers (idx=6, type=4, r=0x8d16860,
+      c=0x0, s=0x813d238, pconf=0x0, plog=0x0, ptemp=0x0,
+      run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:263
+  #9  0x40453c2d in modperl_callback_per_dir (idx=6, r=0x8d16860,
+      run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:351
+  #10 0x4044c728 in modperl_response_handler_run (r=0x8d16860, finish=0)
+      at mod_perl.c:911
+  #11 0x4044cadb in modperl_response_handler_cgi (r=0x8d16860) at mod_perl.c:1006
+  #12 0x080db2bc in ap_run_handler (r=0x8d16860) at config.c:151
+  #13 0x080dba19 in ap_invoke_handler (r=0x8d16860) at config.c:363
+  #14 0x080a9953 in ap_process_request (r=0x8d16860) at http_request.c:246
+  #15 0x080a3ef8 in ap_process_http_connection (c=0x8d10920) at http_core.c:250
+  #16 0x080e7efc in ap_run_process_connection (c=0x8d10920) at connection.c:42
+  #17 0x080e82f8 in ap_process_connection (c=0x8d10920, csd=0x8d10848)
+      at connection.c:175
+  #18 0x080d9b6d in child_main (child_num_arg=0) at prefork.c:609
+  #19 0x080d9c44 in make_child (s=0x813d238, slot=0) at prefork.c:649
+  #20 0x080d9d6a in startup_children (number_to_start=2) at prefork.c:721
+  #21 0x080da177 in ap_mpm_run (_pconf=0x81360a8, plog=0x817e1c8, s=0x813d238)
+      at prefork.c:940
+  #22 0x080e0de8 in main (argc=11, argv=0xbffff284) at main.c:619
+
+That's the perfect back trace to send as a part of the bug report.
+
+Reading the trace from bottom to top, we can see that it starts with
+Apache calls, followed by mod_perl calls which end up in
+C<modperl_callback()> which calls the Perl program via
+C<Perl_call_sv>.
 
 Notice that in our example we knew what script has caused the
-Segmentation fault. In a real world the chances are that you will find 
-the I<core> file without any clue to which of handler or script has
+Segmentation fault. In a real world the chances are that you will find
+the F<core> file without any clue to which of handler or script has
 triggered it. The special I<curinfo> C<gdb> macro comes to help:
 
-  panic% gdb /home/httpd/httpd_perl/bin/httpd_perl /home/httpd/perl/core
-  (gdb) source mod_perl-x.xx/.gdbinit
+For perl enabled with threads that's:
+
+  define curinfo
+     printf "%d:%s\n", my_perl->Tcurcop->cop_line, \
+         my_perl->Tcurcop->cop_file
+  end
+
+For a non-threaded version that's:
+
+  define curinfo
+     printf "%d:%s\n", PL_curcop->cop_line, \
+     ((XPV*)(*(XPVGV*)PL_curcop->cop_filegv->sv_any)\
+     ->xgv_gp->gp_sv->sv_any)->xpv_pv
+  end
+
+Simply past the correct version at the gdb prompt (in this example the
+perl is threaded):
+
+  (gdb) define curinfo
+  Type commands for definition of "curinfo".
+  End with a line saying just "end".
+  >   printf "%d:%s\n", my_perl->Tcurcop->cop_line, \
+         my_perl->Tcurcop->cop_file
+  >end
+
+and now we can call it:
+
   (gdb) curinfo
-  9:/home/httpd/perl/core_dump.pl
+  No symbol "my_perl" in current context.
+
+Oops, the function where the segfault has happened doesn't have the
+perl context, so we need to look at the backtrace and find the first
+function which accepts the C<my_perl> argument (this is because we use
+a threaded perl). In this example this is the second frame:
+
+  #2  0x407ab39b in XS_Debug__DumpCore_segv (my_perl=0x86a9298, cv=0x8d36750)
+      at DumpCore.xs:26
+
+therefore we need to go two frames up:
+
+  (gdb) up 2
+  #2  0x407ab39b in XS_Debug__DumpCore_segv (my_perl=0x86a9298, cv=0x8d36750)
+      at DumpCore.xs:26
+  26      in DumpCore.xs
+
+and now we call C<curinfo> again:
+
+  gdb) curinfo
+  14:/home/httpd/cgi-bin/core_dump.pl
+
+Et voilą, we can see that the segfault was triggered on line 14 of
+F<core_dump.pl>, which has the line:
+
+  Debug::DumpCore::segv();
+
+And we are done.
+
+These are the bits of information that are important to extract and
+include in your bug report in order for us to be able to reproduce and
+resolve a problem. In this example it was the full backtrace, the
+filename and line where the faulty function was called (the faulty
+function is C<Debug::DumpCore::segv()>) and the actual line where the
+Segmentation fault occured (C<crash_now_for_real> at
+C<DumpCore.xs:10>).
+
+
+
+
+=head2 Analyzing the core File Automatically
+
+If the core file(s) are found in the mod_perl source directory, when
+running F<t/REPORT> the core file backtraces will be automatically
+extracted and added to the report if the perl module C<Devel::GDB> is
+installed.
+
+See the function C<dump_core_file()> in
+F<Apache-Test/lib/Apache/TestReport.pm> if you want to see how it is
+invoked or refer to the C<Devel::GDB> manpage.
+
+
+
+
 
-We start the C<gdb> debugger as before.  I<.gdbinit>, the file with
-various useful C<gdb> macros is located in the source tree of
-mod_perl. We use the C<gdb> source() function to load these macros,
-and when we run the I<curinfo> macro we learn that the core was dumped
-when I</home/httpd/perl/core_dump.pl> was executing the code at line
-9.
-
-These are the bits of information that are important in order to
-reproduce and resolve a problem: the filename and line where the
-faulty function was called (the faulty function is Bad::Segv::segv()
-in our case) and the actual line where the Segementation fault occured
-(the printf("%d",*p) call in XS code). The former is important for
-problem reproducing, it's possible that if the same function was
-called from a different script the problem won't show up (not the case
-in our example, where the using of a value dereferenced from the NULL
-pointer will always cause the Segmentation fault).
 
 
 =head2 Obtaining core Files under Solaris
@@ -821,13 +874,13 @@
 
 =item 1
 
-Use gcore(1) to get a I<core> of stopped process or attach to it with
+Use gcore(1) to get a F<core> of stopped process or attach to it with
 gdb(1).  For example if the process id is 662:
 
-  %panic gcore 662
+  panic% gcore 662
   gcore: core.662 dumped
 
-Now you can load this I<core> file in gdb(1).
+Now you can load this F<core> file in gdb(1).
 
 =item 1
 

Modified: perl/modperl/docs/trunk/src/docs/2.0/user/help/help.pod
Url: http://svn.apache.org/viewcvs/perl/modperl/docs/trunk/src/docs/2.0/user/help/help.pod?view=diff&rev=106364&p1=perl/modperl/docs/trunk/src/docs/2.0/user/help/help.pod&r1=106363&p2=perl/modperl/docs/trunk/src/docs/2.0/user/help/help.pod&r2=106364
==============================================================================
--- perl/modperl/docs/trunk/src/docs/2.0/user/help/help.pod	(original)
+++ perl/modperl/docs/trunk/src/docs/2.0/user/help/help.pod	Tue Nov 23 16:34:15 2004
@@ -205,53 +205,22 @@
 
 At the moment the second test suite is not run if the first one fails.
 
-=head2 Resolving Segmentation Faults
-
-If during C<make test> or the use of mod_perl you get a segmentation
-fault you should send to the list a stack backtrace. This
-L<section|devel::debug::c/Analyzing_Dumped_Core_Files> explains how to
-extract this backtrace.
-
-Of course to generate a useful backtrace you need to have mod_perl
-with debugging symbols in it (and probably perl and/or httpd too) and
-also to be able to see the arguments in the calls trace. To accomplish
-that do:
-
-=over
-
-=item * mod_perl
 
-rebuild mod_perl with C<MP_DEBUG=1>.
 
-  % perl Makefile.PL MP_DEBUG=1 ...
-  % make && make test && make install
 
-=item * httpd
-
-If the segfault happens inside I<ap_> or I<apr_> calls, rebuild httpd
-with C<--enable-maintainer-mode>:
-
-  % ./configure --enable-maintainer-mode ...
-  % make && make install
-
-=item * perl
+=head2 Resolving Segmentation Faults
 
-If the segfault happens inside I<Perl_> calls, rebuild perl with
-C<-Doptimize='-g'>:
+If during C<make test> or the use of mod_perl you get a segmentation
+fault you should send to the list a stack backtrace.  L<This
+section|devel::debug::c/Analyzing_Dumped_Core_Files> explains how to
+get the core file and extract this backtrace. Once a proper stack
+backtrace is obtained append it to the bug report as explained in the
+previous section.
 
-  % ./Configure -Doptimize='-g' ...
-  % make && make test && make install
 
-=item * 3rd party perl modules
 
-if the trace happens in one of the 3rd party perl modules, make sure
-to rebuild them, now that you've perl re-built with debugging
-flags. They will automatically pick the right compile flags from perl.
 
-=back
 
-Once a proper stack backtrace is obtained append it to the bug report
-as explained in the previous section.
 
 =head2 Please Ask Only Questions Related to mod_perl
 

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-cvs-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-cvs-help@perl.apache.org


Mime
View raw message