[CC'ing back to the list for archival and possibly interesting followup
discussion]
On Mon, 6 Aug 2001, Kyle Oppenheim wrote:
> Here's another method to generate a core on Solaris that you may want to add
> to the guide. (I hope I'm not repeating something already in the guide!)
>
> 1. Use truss(1) as root to stop a process on a segfault:
>
> truss -f -l -t \!all -s \!SIGALRM -S SIGSEGV -p <pid>
>
> or, to monitor all httpd processes (from bash):
>
> for pid in `ps -eaf -o pid,comm | fgrep httpd | cut -d'/' -f1`;
> do truss -f -l -t \!all -s \!SIGALRM -S SIGSEGV -p $pid 2>&1 &
> done
what happens to the newly spawned processes?
what happens if the process segfaults immediately after it starts. You
don't have enough time to get its PID.
> 2. Watch the server error_log for reaped processes
>
> 3. Use gcore to get a core of stopped process or attach gdb.
>
> 4. kill -9 the stopped process.
Since I don't have an access to a Solaris system, is it possible for you
to take the example code I've supplied below and apply these steps to it?
So we can get a fully working example? Thanks a lot! (for example I'm not
familiar with gcore... is it Solaris specific thing?)
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Stas Bekman
> Sent: Friday, August 03, 2001 7:53 PM
> To: Andrei A. Voropaev
> Cc: [EMAIL PROTECTED]
> Subject: Re: Segfaults
>
>
> On Fri, 3 Aug 2001, Andrei A. Voropaev wrote:
>
> > Hi!
> >
> > The problem with Apache/mod_perl children segfaulting is pretty old.
> Unfortunately this
> > does not leave any core dump that would help in tracing the problem. All
> it
> > leaves is messages in error log
> >
> > [Fri Aug 3 05:39:28 2001] [notice] child pid 446 exit signal Segmentation
> > fault (11)
> >
> > And quite a lot of them. The more we use mod_perl the more messages like
> this.
> > A year ago we had only authentication in mod_perl and these message showed
> up
> > 5-6 times a day. Now we run Mason (v 0.89) and the messages show up 2-3
> times
> > a minute. (This has nothing to do with increased usage) The problem has
> > survived 3 upgrades (we started with mod_perl/1.21)
> >
> > So my question is - is there any way to force coredumps? :)
>
> This is an excerpt from the upcoming book (which we will finish at some
> point :)
>
> =head2 Getting the core File Dumped
>
> Now let's get the I<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
> 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:
>
> =over
>
> =item *
>
> 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 *
>
> 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.
>
> =item *
>
> be started from a shell process with sufficient resource allocations
> for the I<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.
>
> You can use C<ulimit> for C<bash> and C<limit> for C<csh> to check and
> adjust the resource allocation. For example inside C<bash>, you may
> set the core file size to unlimited:
>
> panic% ulimit -c unlimited
>
> For example you can set an upper limit on the I<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 *
>
> 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).
>
> =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
> be dumped. Instead it allows you to examine the program stack and
> other things without having the I<core> file.
>
> So let's write a simple script that uses C<Bad::Segv>:
>
> core_dump.pl
> ------------
> use strict;
> use Bad::Segv ();
> use Cwd()
>
> my $r = shift;
> $r->send_http_header("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.
>
> Before we run the script we make sure that the shell sets the I<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% limit coredumpsize unlimited
> panic% ./httpd_perl -X
> # issue a request here
> Segmentation fault (core dumped)
>
> Our browser prints out:
>
> The core should be found at /home/httpd/perl/core
>
> 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):
>
> panic% ls -l /home/httpd/perl/core
> -rw------- 1 stas httpd 3227648 Feb 7 18:53 /home/httpd/perl/core
>
> As you can see it's a 3MB I<core> file. Notice that mod_perl was
> started as user I<stas>, which had write permission for directory
> I</home/httpd/perl>.
>
>
>
> _____________________________________________________________________
> Stas Bekman JAm_pH -- Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide http://perl.apache.org/guide
> mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
> http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
>
>
>
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
