Re: Here is my backtrace, please solove my problem

[Barrie Slaymaker <ba...@slaysys.com>]

[Note the Reply-To]

You're getting closer.  Unfortunately, the backtrace you sent says
that gdb attached to a running httpd and it happened to be sitting in
select() when gdb attached on to it.  At which point you grabbed the
backtrace and exited, killing the httpd before recreating the problem.

Instead, you need to cause the problem while debugging the httpd and,
assuming it segfaults when in gdb, get the backtrace from where the
problem occurred.

Try the first recipe from SUPPORT:

 % 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

or do what you did but gdb's 'continue' command to get the httpd to run
again and make the offending request over and over until you get it to
seg fault, *then* do the 'where'/'bt' command.

The stack trace needs to be from the point of failure, not from some
place in a (so far) healthy server...

If you have a core file from the segfault, you can also do that recipe
from SUPPORT:

 % gdb httpd core

and do the 'bt' that's often a bit easier.

- Barrie

Re: Here is my backtrace, please solove my problem

[Barrie Slaymaker <ba...@slaysys.com>]

On Sat, Nov 10, 2001 at 12:10:03PM -0800, SubbaReddy M wrote:
> 
> /soft/Apache-ASP-2.27/make_httpd/mod_perl-1.26/core: No such file or directory.

You need a core file to do this... gdb is kindly pointing out that you
don't have one.

> and i am really thankfull for your help.

I'm just (repeatedly) telling you to read the manual and think about
what you are doing.  You need to understand how the debugger, the stack,
seg faults, and core dumps work in relation to one another and this list
is not the place to learn all that.

Sorry,

Barrie

Re: Here is my backtrace, please solove my problem

[SubbaReddy M <m_...@hotmail.com>]

This is, i am geting.............

[root@qclinux mod_perl-1.26]# gdb httpd core
GNU gdb 19991004
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...(no debugging symbols
found)...

/soft/Apache-ASP-2.27/make_httpd/mod_perl-1.26/core: No such file or
directory.
(gdb) bt
No stack.
(gdb) /bt
Undefined command: "".  Try "help".
(gdb) continue
The program is not being run.
(gdb) run -X -f `pwd`/t/conf/httpd.conf -d `pwd`/t
Starting program: /usr/sbin/httpd -X -f `pwd`/t/conf/httpd.conf -d `pwd`/t
Ouch! ap_mm_create(1048576,
"/soft/Apache-ASP-2.27/make_httpd/mod_perl-1.26/t/tmp/mm.19659") failed
Error: MM: mm:core: failed to open semaphore file (No such file or
directory): OS: No such file or directory

Program exited with code 01.
(gdb) Quit
(gdb) bt
No stack.
(gdb)



and i am really thankfull for your help.

-SubbaReddy

----- Original Message -----
From: "Barrie Slaymaker" <ba...@slaysys.com>
To: "SubbaReddy M" <m_...@hotmail.com>
Cc: <mo...@apache.org>
Sent: Friday, November 09, 2001 10:09 PM
Subject: Re: Here is my backtrace, please solove my problem


> [Note the Reply-To]
>
> You're getting closer.  Unfortunately, the backtrace you sent says
> that gdb attached to a running httpd and it happened to be sitting in
> select() when gdb attached on to it.  At which point you grabbed the
> backtrace and exited, killing the httpd before recreating the problem.
>
> Instead, you need to cause the problem while debugging the httpd and,
> assuming it segfaults when in gdb, get the backtrace from where the
> problem occurred.
>
> Try the first recipe from SUPPORT:
>
>  % 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
>
> or do what you did but gdb's 'continue' command to get the httpd to run
> again and make the offending request over and over until you get it to
> seg fault, *then* do the 'where'/'bt' command.
>
> The stack trace needs to be from the point of failure, not from some
> place in a (so far) healthy server...
>
> If you have a core file from the segfault, you can also do that recipe
> from SUPPORT:
>
>  % gdb httpd core
>
> and do the 'bt' that's often a bit easier.
>
> - Barrie
>