Re: Apache::DProf problems

[Perrin Harkins]

On Sat, 2003-08-30 at 15:34, Brian Hirt wrote:
> i'll double check, but i'm fairly certain it's loaded first.

If you post your conf, we could probably help you more.

> what if a module is loaded after the fact, but like this:   eval { use 
> $module };

Doesn't matter.  You just have to initialize the debugger.  I do this by
calling Apache::DB->init because I don't want to actually profile
anything during startup but I do need the debugger turned on when I
compile code at startup for DProf to work.

- Perrin


-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: Apache::DProf problems

[Brian Hirt]

i'll double check, but i'm fairly certain it's loaded first.

what if a module is loaded after the fact, but like this:   eval { use 
$module };

some modules are dynamically loaded at run time depending on certain 
situations.

On Friday, August 29, 2003, at 04:26 PM, Stas Bekman wrote:

Brian Hirt wrote:
I've installed Apache::DProf, but it seems hardly any of the calls 
are profiled.   dprofpp shouws MOF::Dispatcher::handler as taking up 
100% of the time, but there is no information recorded in for calls 
within that function.  MOF::Dispatcher::handler is calling thousands 
of other functions and there is absolutely no record of any of those 
calls in tmon.out.
Any ideas an what's going on?  I'm running mp1.27 and compiled it 
with EVERYTHING=1
Remember that any PerlHandler that was pulled in before Apache::DProf 
in the httpd.conf or startup.pl file will not have code-debugging 
information inserted. Make sure that you load before any code that you 
plan to profile.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: Apache::DProf problems

[Stas Bekman]

Brian Hirt wrote:
I've installed Apache::DProf, but it seems hardly any of the calls are 
profiled.   dprofpp shouws MOF::Dispatcher::handler as taking up 100% of 
the time, but there is no information recorded in for calls within that 
function.  MOF::Dispatcher::handler is calling thousands of other 
functions and there is absolutely no record of any of those calls in 
tmon.out.

Any ideas an what's going on?  I'm running mp1.27 and compiled it with 
EVERYTHING=1
Remember that any PerlHandler that was pulled in before Apache::DProf in the 
httpd.conf or startup.pl file will not have code-debugging information 
inserted. Make sure that you load before any code that you plan to profile.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: Apache::DProf problems

[Perrin Harkins]

On Fri, 2003-08-29 at 17:11, Brian Hirt wrote:
> I've installed Apache::DProf, but it seems hardly any of the calls are 
> profiled.

You probably compiled that code before you initialized the debugger. 
Add a call to Apache::DB->init before you load your modules, as
described in the Apache::DB docs.

- Perrin


-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Apache::DProf problems

[Brian Hirt]

I've installed Apache::DProf, but it seems hardly any of the calls are 
profiled.   dprofpp shouws MOF::Dispatcher::handler as taking up 100% 
of the time, but there is no information recorded in for calls within 
that function.  MOF::Dispatcher::handler is calling thousands of other 
functions and there is absolutely no record of any of those calls in 
tmon.out.

Any ideas an what's going on?  I'm running mp1.27 and compiled it with 
EVERYTHING=1

[EMAIL PROTECTED] modperl]# dprofpp logs/dprof/2734/tmon.out
Total Elapsed Time = 7.359757 Seconds
  User+System Time = 0.349757 Seconds
Exclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c  Name
 100.   0.350  0.350  1   0.3499 0.3499  MOF::Dispatcher::handler
 0.00   0.000 -0.000  1   0.  -  
MOF::Dispatcher::ProxyCleanup::handler
 0.00   0.000 -0.000  8   0.  -  Apache::Table::TIEHASH
 0.00   0.000 -0.000  1   0.  -  Apache::Table::FETCH
 0.00   0.000 -0.000 16   0.  -  Apache::Table::DESTROY
 0.00   0.000 -0.000  5   0.  -  MOF::DBObject::DESTROY
 0.00   0.000 -0.000 14   0.  -  DBD::Pg::db::prepare
 0.00   0.000 -0.000 14   0.  -  DBI::st::TIEHASH
 0.00   0.000 -0.000 28   0.  -  DBI::st::DESTROY
 0.00   0.000 -0.000 14   0.  -  DBD::_mem::common::DESTROY
 0.00   0.000 -0.000  8   0.  -  IO::Handle::DESTROY
 0.00   0.000 -0.000  1   0.  -  DBD::Pg::db::quote
 0.00   0.000 -0.000  7   0.  -  Apache::PRINT
 0.00   0.000 -0.000  2   0.  -  Image::Magick::DESTROY
 0.00   0.000 -0.000  1   0.  -  MOF::Object::DESTROY



--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: Apache::DProf not working

[Stas Bekman]

Randy Harmon wrote:
> I'm having trouble making Apache::DProf work.
> 
> I've installed the module with CPAN, and I've added PerlModule Apache::DProf
> at the top of my httpd.conf.  I've verified with 'httpd -l' that
> PerlChildInitHandler is OK - therefore, pushing a child-init handler should
> be OK, right?
> 
> I've started the server, ran the web page I want to profile (that uses
> HTML::Mason), and then stopped the server.
> 
> ServerRoot/dprof is not created, nor when I create it does it create
> dprof/$$ files as documented (likewise ServerRoot/logs/dprof/, as described
> elsewhere in the perldoc - not self-consistent).  Also searched the entire
> system for tmon.out files (not found).
> 
> Any suggestions?

Permission problems?



__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Apache::DProf not working

[Randy Harmon]

I'm having trouble making Apache::DProf work.

I've installed the module with CPAN, and I've added PerlModule Apache::DProf
at the top of my httpd.conf.  I've verified with 'httpd -l' that
PerlChildInitHandler is OK - therefore, pushing a child-init handler should
be OK, right?

I've started the server, ran the web page I want to profile (that uses
HTML::Mason), and then stopped the server.

ServerRoot/dprof is not created, nor when I create it does it create
dprof/$$ files as documented (likewise ServerRoot/logs/dprof/, as described
elsewhere in the perldoc - not self-consistent).  Also searched the entire
system for tmon.out files (not found).

Any suggestions?

Randy

Re: Apache::DProf

[Chris Newman]

Think you need to load in Apache::Registry with :

PerlModule Apache::Registry

before the PerlHandler Apache::Registry bit
Suggest also that you do all the module loading / startup before specifying 
any handlers

eg . from my mod_perl.conf

PerlRequire conf/startup.pl
PerlFreshRestarton

PerlSetVar StatusOptionsAll On
PerlSetVar StatusTerse On
PerlSetVar StatusTerseSize On
PerlSetVar StatusTerseSizeMainSummary On

Alias /perl-bin/ /usr/local/apache/mod_perl/

PerlModule Apache::DProf
PerlModule Apache::Registry
PerlModule B::TerseSize
PerlModule Apache::Status


SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
PerlSendHeader On
allow from all


On Wednesday 24 Jul 2002 2:20 pm, Ruslan V. Sulakov wrote:
> I have troubles using Apache::DProf
> I try to use it as described at:
> http://perl.apache.org/docs/1.0/guide/performance.html#Code_Profiling_Techn
>i ques
>
> But when my httpd.conf has a line:
>     PerlModule Apache::DProf
> apache reply with error 500 (Internal Server Error) when I request a perl
> script, that runs under mod_perl
>
> Without this line, all works fine!
>
> Errorlog shows following message during each request:
> [Sat Jul 20 07:34:28 2002] [error] Undefined subroutine
> &Apache::Registry::handler called.
>
>
> I have in my httpd.conf
> 
>   SetHandler  perl-script
>   PerlHandler Apache::Registry
>   PerlSendHeader On
>   Options +ExecCGI
>   PerlModule Apache::DProf
>   PerlRequire /path/to/my/modules/modperl_startup.pl
> 
>
> Is here something wrong?
> How can I have Apache::DProf worked for profiling my code?
>
> Thanks in advance.
> Ruslan

Apache::DProf

[Ruslan V. Sulakov]

I have troubles using Apache::DProf
I try to use it as described at:
http://perl.apache.org/docs/1.0/guide/performance.html#Code_Profiling_Techni
ques

But when my httpd.conf has a line:
PerlModule Apache::DProf
apache reply with error 500 (Internal Server Error) when I request a perl
script, that runs under mod_perl

Without this line, all works fine!

Errorlog shows following message during each request:
[Sat Jul 20 07:34:28 2002] [error] Undefined subroutine
&Apache::Registry::handler called.


I have in my httpd.conf

  SetHandler  perl-script
  PerlHandler Apache::Registry
  PerlSendHeader On
  Options +ExecCGI
  PerlModule Apache::DProf
  PerlRequire /path/to/my/modules/modperl_startup.pl


Is here something wrong?
How can I have Apache::DProf worked for profiling my code?

Thanks in advance.
Ruslan

Apache::DProf seg-fault found

[Sam Tregar]

I think I've isolated the cause of my Apache::DProf seg-faults.  The
seg-fault occurs inside Devel::DProf's prof_mark() routine.  When it
occurs the magic PL_DBsub variable, known to Perl as $DB::sub contains:

 SV = PVGV(0x8208960) at 0x970927c
  REFCNT = 1
  FLAGS = (GMG,SMG,MULTI)
  IV = 0
  NV = 0
  MAGIC = 0x97173b8
MG_VIRTUAL = &PL_vtbl_glob
MG_TYPE = '*'
MG_OBJ = 0x970927c
  NAME = "sub"
  NAMELEN = 3
  GvSTASH = 0x81fa380   "DB"
  GP = 0x9717380
SV = 0x97156cc
REFCNT = 1
IO = 0x0
FORM = 0x0
AV = 0x0
HV = 0x97092dc
CV = 0x82085d0
CVGEN = 0x0
GPFLAGS = 0x0
LINE = 17
FILE = "/usr/local/lib/perl5/site_perl/5.6.1/i686-linux/Apache/DB.pm"
FLAGS = 0x2
EGV = 0x970927c "sub"

Then prof_mark() calls GvSV() on it and gets:

 SV = PVIV(0x9730d60) at 0x97156cc
  REFCNT = 1
  FLAGS = (IOK,pIOK)
  IV = 0
  PV = 0

Which is then passed to INT2PTR() yielding a NULL pointer in a CV *, which
is later used.  Bang.

Now, by tracing my app I've determined that this is happening when my main
mod_perl PerlHandler returns after certain operations (not all, but I
don't know what's special about the ones that cause the problem).  In a
moment of madness I inserted this code into my handler():

  $DB::sub += 0;

And it works!  I have no idea why I thought this would work, but with that
line in my handler() I no longer get any seg-faults from Apache::DProf.

Question: how did $DB::sub get into a bad state such that GvSV()
produced an SV containing IV == 0 and PV == 0?  Does anyone have any
suggestions as to how I could find out?  I've been getting most of my info
via strategicly placed warn()s inside DProf.xs and gdb.

Thanks!
-sam

Re: Apache::DProf seg faulting

[Perrin Harkins]

Paul Lindner wrote:
>>But while I have your attention, why are you using Apache::DB at all?  The
>>Apache::DProf docs just have:
>>
>>  PerlModule Apache::DProf
> 
> 
> Legacy knowledge :)
> 
> I think it may have been required in the past, or perhaps I had some
> problems with my INC paths long-long ago..  And well, it just kinda
> stuck.

I used to do it because if I didn't DProf would not know anything about 
modules I pull in from startup.pl (since the debugger was not 
initialized until after they were loaded).  This may not be necessary 
anymore.

- Perrin

Re: Apache::DProf seg faulting

[Paul Lindner]

On Thu, Apr 18, 2002 at 02:18:04AM -0400, Sam Tregar wrote:
> On Wed, 17 Apr 2002, Paul Lindner wrote:
> 
> > Geoffrey and I tested our environments today and the recipe given in
> > the book seems to work just fine:
> >
> >   PerlModule Apache::DB
> >   PerlModule Apache::DProf
> 
> With those lines I get a seg-fault on the first hit to the server.
> Reversing the lines I can get a few hits before seg-faulting.  I doubt
> it's a problem in your example - something inside Devel::DProf is
> seg-faulting as far as I can tell.  I'm planning to build a debugging
> Perl and see if I can get more information.
> 
> But while I have your attention, why are you using Apache::DB at all?  The
> Apache::DProf docs just have:
> 
>   PerlModule Apache::DProf

Legacy knowledge :)

I think it may have been required in the past, or perhaps I had some
problems with my INC paths long-long ago..  And well, it just kinda
stuck.

I hope you find your problems.  DProf is a very useful tool, and it's
worth the effort to get it working..

-- 
Paul Lindner[EMAIL PROTECTED]   | | | | |  |  |  |   |   |

mod_perl Developer's Cookbook   http://www.modperlcookbook.org/
 Human Rights Declaration   http://www.unhchr.ch/udhr/

Re: Apache::DProf seg faulting

[Geoffrey Young]

>>Geoffrey and I tested our environments today and the recipe given in
>>the book seems to work just fine:
>>
>>  PerlModule Apache::DB
>>  PerlModule Apache::DProf
>>
> 
> With those lines I get a seg-fault on the first hit to the server.
> Reversing the lines I can get a few hits before seg-faulting.  I doubt
> it's a problem in your example - something inside Devel::DProf is
> seg-faulting as far as I can tell.  I'm planning to build a debugging
> Perl and see if I can get more information.


that's the position I'd take, at least as far as the book is concerned.

we made the deliberate decision to not talk about mod_perl bugs in the 
book and instead focus on how mod_perl _should_ behave.

I was able to get it to work as the book suggests just fine with 
bleeding edge everything, so it may be an issue with Perl as Ged 
suggested.  since it works as given for both Paul and I we'll probably 
not put it in as errata.  that it segfaults is also another sign that 
whatever issue you're having is a bug (of some sort) and not really a 
misconfiguration.


> 
> But while I have your attention, why are you using Apache::DB at all?  The
> Apache::DProf docs just have:
> 
>   PerlModule Apache::DProf


yes.  however, PerlModule is useful for loading modules you know you'll 
use, and Apache::DProf pulls in Apache::DB.

I just looked at the DProf.pm code today for the first time and found it 
rather interesting (some stuff snipped):

Apache->push_handlers(PerlChildInitHandler => \&handler);

sub handler {
 my $r = shift;

...

 Apache::DB->init;
...


so, this kinda explains why PerlModule Apache::DProf works all by itself 
as the docs (and Perrin's june 2000 post) indicate.  of course, now I'm 
confused by why Perrin needed to call Apache::DB->init() in a  
section at all, since that's loaded by a different interpreter than the 
children, which is what you want to measure.  any ideas Perrin?

anyway, thanks for bringing this up, Sam.  we've actually closed the 
book on errata for the second printing but will continue to add those 
that readers find for subsequent printings (or editions).  keep them 
coming :)

--Geoff

Re: Apache::DProf seg faulting

[Ged Haywood]

Hi there,

On Thu, 18 Apr 2002, Sam Tregar wrote:

> - something inside Devel::DProf is seg-faulting as far as I can tell.

Oops.  Didn't cc the List.

73,
Ged.

--

Date: Wed, 17 Apr 2002 09:53:08 +0100 (BST)
Subject: Re: Apache::DProf seg faulting

On Tue, 16 Apr 2002, Sam Tregar wrote:

> It looks like the poison pill is loading Apache::DB before Apache::DProf.
> Odd, eh?

Sorry, I haven't been following the thread so please feel free to
ignore me.  I had some problems with Devel:DProf and dprofpp using
Perl 5.7.1 which went away when I upgraded to 5.7.2.  Dunno if that's
relevant or not...

73,
Ged.

 

Re: Apache::DProf seg faulting

[Sam Tregar]

On Wed, 17 Apr 2002, Paul Lindner wrote:

> I think that this may be a problem with the use of  sections.
>
> I believe your original post had something like this:
>
> 
>   use Apache::DProf
>   use Apache::DB
>   Apache::DB->init();
> 

Nope.  That was Perrin Harkins, but I tried it too!

> Geoffrey and I tested our environments today and the recipe given in
> the book seems to work just fine:
>
>   PerlModule Apache::DB
>   PerlModule Apache::DProf

With those lines I get a seg-fault on the first hit to the server.
Reversing the lines I can get a few hits before seg-faulting.  I doubt
it's a problem in your example - something inside Devel::DProf is
seg-faulting as far as I can tell.  I'm planning to build a debugging
Perl and see if I can get more information.

But while I have your attention, why are you using Apache::DB at all?  The
Apache::DProf docs just have:

  PerlModule Apache::DProf

-sam

Re: Apache::DProf seg faulting

[Paul Lindner]

On Tue, Apr 16, 2002 at 06:05:11PM -0400, Sam Tregar wrote:
> On Tue, 16 Apr 2002, Sam Tregar wrote:
> 
>  > On 16 Apr 2002, Garth Winter Webb wrote:
>  >
>  > > Sam, try getting rid of the 'PerlModule Apache::DB' line.  I've used
>  > > Apache::DProf w/o any problems by including only the one PerlModule
>  > > line.  Since they both want to use perl debugging hooks, I'm guessing
>  > > that Apache::DProf is getting crashed up when it tries to use hooks
>  > > already grabbed by Apache::DB...
>  >
>  > Same result.  Thanks though!
> 
> Aw nuts, that was the problem!  I thought I'd tried that already, but I
> guess not.  I actually got those PerlModule lines from the "mod_perl
> Developers Cookbook" - guess this is an errata!

I think that this may be a problem with the use of  sections.

I believe your original post had something like this:


  use Apache::DProf
  use Apache::DB
  Apache::DB->init();


Geoffrey and I tested our environments today and the recipe given in
the book seems to work just fine:

  PerlModule Apache::DB
  PerlModule Apache::DProf


-- 
Paul Lindner[EMAIL PROTECTED]   | | | | |  |  |  |   |   |

mod_perl Developer's Cookbook   http://www.modperlcookbook.org/
 Human Rights Declaration   http://www.unhchr.ch/udhr/

Re: Apache::DProf seg faulting

[Sam Tregar]

On Tue, 16 Apr 2002, Perrin Harkins wrote:

> Strange, that works for me.  I do it like this:
> 
>  use Apache::DProf;
>  use Apache::DB;
>  Apache::DB->init;
> 

That works, but this doesn't:

  
   use Apache::DB;
   use Apache::DProf;
   Apache::DB->init;
  

It looks like the poison pill is loading Apache::DB before Apache::DProf.
Odd, eh?

-sam

Re: Apache::DProf seg faulting

[Perrin Harkins]

Sam Tregar wrote:
> On Tue, 16 Apr 2002, Sam Tregar wrote:
> 
> 
>>On 16 Apr 2002, Garth Winter Webb wrote:
>>
>>
>>>Sam, try getting rid of the 'PerlModule Apache::DB' line.  I've used
>>>Apache::DProf w/o any problems by including only the one PerlModule
>>>line.  Since they both want to use perl debugging hooks, I'm guessing
>>>that Apache::DProf is getting crashed up when it tries to use hooks
>>>already grabbed by Apache::DB...
>>
>>Same result.  Thanks though!
> 
> 
> Aw nuts, that was the problem!  I thought I'd tried that already, but I
> guess not.  I actually got those PerlModule lines from the "mod_perl
> Developers Cookbook" - guess this is an errata!

Strange, that works for me.  I do it like this:

 use Apache::DProf;
 use Apache::DB;
 Apache::DB->init;


Or at least I did last time.  Maybe this has changed in more recent 
versions.  At the time (June 2000), I discovered I needed to call 
Apache::DB->init or else the debugging symbols would not get put in for 
modules that I used in my startup.pl, and they would not get profiled.

- Perrin

Re: Apache::DProf seg faulting

[Sam Tregar]

On Tue, 16 Apr 2002, Sam Tregar wrote:

> On 16 Apr 2002, Garth Winter Webb wrote:
>
> > Sam, try getting rid of the 'PerlModule Apache::DB' line.  I've used
> > Apache::DProf w/o any problems by including only the one PerlModule
> > line.  Since they both want to use perl debugging hooks, I'm guessing
> > that Apache::DProf is getting crashed up when it tries to use hooks
> > already grabbed by Apache::DB...
>
> Same result.  Thanks though!

Aw nuts, that was the problem!  I thought I'd tried that already, but I
guess not.  I actually got those PerlModule lines from the "mod_perl
Developers Cookbook" - guess this is an errata!

Thanks!
-sam

Re: Apache::DProf seg faulting

[Sam Tregar]

On 16 Apr 2002, Garth Winter Webb wrote:

> Sam, try getting rid of the 'PerlModule Apache::DB' line.  I've used
> Apache::DProf w/o any problems by including only the one PerlModule
> line.  Since they both want to use perl debugging hooks, I'm guessing
> that Apache::DProf is getting crashed up when it tries to use hooks
> already grabbed by Apache::DB...

Same result.  Thanks though!

-sam

Apache::DProf seg faulting

[Sam Tregar]

Hello all.  I'm trying to use Apache::DProf but all I get is seg faults.
I put these lines in my httpd.conf:

  PerlModule Apache::DB
  PerlModule Apache::DProf

Then I start the server, and it looks ok:

  [Tue Apr 16 17:22:12 2002] [notice] Apache/1.3.20 (Unix) mod_perl/1.25
  mod_ssl/2.8.4 OpenSSL/0.9.6a configured -- resuming normal operations
  [Tue Apr 16 17:22:12 2002] [info] Server built: Aug 17 2001 13:29:44
  [notice] Apache::DB initialized in child 2234
  [notice] Apache::DB initialized in child 2235

I hit the server and I get:

  [Tue Apr 16 17:22:17 2002] [notice] child pid 2235 exit signal
  Segmentation fault (11)
  [notice] Apache::DB initialized in child 2237

Looking in logs/dprof I see a bunch of numeric directories with tmon.out
files in them.  All the around same size (400 bytes).

Any suggestions on how to proceed?

-sam

Re: Apache::DProf tip

[Doug MacEachern]

On Tue, 26 Sep 2000, Perrin Harkins wrote:

> On Tue, 26 Sep 2000, Doug MacEachern wrote:
> > the Apache::DB docs explain this:
> 
> The connection between Apache::DProf and calling something in Apache::DB
> was not obvious to me until I thought about how DProf works.

yeah, i was actually surprised to find that it was documented anywhere ;)
 
> I'd be happy to write up a little documentation patch for it.  I'll send
> it to you.

that'd be great, thanks!

Re: Apache::DProf tip

[Perrin Harkins]

On Tue, 26 Sep 2000, Doug MacEachern wrote:
> the Apache::DB docs explain this:

The connection between Apache::DProf and calling something in Apache::DB
was not obvious to me until I thought about how DProf works.

> it should probably be made more clear though, maybe a comment in the
> config example.

I'd be happy to write up a little documentation patch for it.  I'll send
it to you.

- Perrin

Re: Apache::DProf tip

[Doug MacEachern]

On Sat, 10 Jun 2000, Perrin Harkins wrote:

> Here's something that might be obvious to others but took me a while to
> figure out:
> 
> If you want to get useful profiling information, you need to initialize
> the debugger before your modules get compiled.  If you pull in your
> modules from startup.pl, you can accomplish this by putting a block like
> this in your httpd.conf before the "PerlRequire startup.pl" statement:
> 
> 
> use Apache::DProf;
> use Apache::DB;
>     Apache::DB->init;
> 
> 
> The "PerlModule Apache::DProf" directove suggested in the Apache::DProf
> docs also seems to work, but be careful because load order seems to matter
> here.

the Apache::DB docs explain this:

=item init

This function initializes the Perl debugger hooks without actually
starting the interactive debugger.  In order to debug a certain piece
of code, this function must be called before the code you wish debug
is compiled.

--

it should probably be made more clear though, maybe a comment in the
config example.

Apache::DProf tip

[Perrin Harkins]

Here's something that might be obvious to others but took me a while to
figure out:

If you want to get useful profiling information, you need to initialize
the debugger before your modules get compiled.  If you pull in your
modules from startup.pl, you can accomplish this by putting a block like
this in your httpd.conf before the "PerlRequire startup.pl" statement:


    use Apache::DProf;
use Apache::DB;
Apache::DB->init;


The "PerlModule Apache::DProf" directove suggested in the Apache::DProf
docs also seems to work, but be careful because load order seems to matter
here.

- Perrin

Apache::DProf woes

[Ask Bjoern Hansen]

I have some problems with Devel::DProf ... after running a few requests I
get either when it boots:

Program received signal SIGSEGV, Segmentation fault.
0x40113eec in chunk_free (ar_ptr=0x401a8040, p=0x81d3668) at malloc.c:3047
3047malloc.c: No such file or directory.
(gdb) bt
#0  0x40113eec in chunk_free (ar_ptr=0x401a8040, p=0x81d3668) at
malloc.c:3047
#1  0x401148a5 in chunk_realloc (ar_ptr=0x401a8040, oldp=0x81d3668,
oldsize=1736, nb=2600)
at malloc.c:3351
#2  0x40114344 in __libc_realloc (oldmem=0x81d3670, bytes=2592) at
malloc.c:3190
#3  0x81090cb in Perl_saferealloc ()
#4  0x40015113 in prof_mark ()
   from
/home/value/apps/perl5.005_03/lib/site_perl/5.005/i686-linux/auto/Devel/DProf/DProf.so
#5  0x400158e9 in XS_DB_sub ()
   from
/home/value/apps/perl5.005_03/lib/site_perl/5.005/i686-linux/auto/Devel/DProf/DProf.so
#6  0x8114056 in Perl_pp_entersub ()
#7  0x80e03ec in perl_call_sv ()
#8  0x80e25c9 in perl_call_method ()
#9  0x808a8d8 in perl_tie_hash ()
#10 0x8089026 in perl_section ()
#11 0x809f039 in ap_clear_module_list ()
#12 0x809fab3 in ap_handle_command ()
#13 0x809fb47 in ap_srm_command_loop ()
#14 0x809ff50 in ap_process_resource_config ()
#15 0x80a0812 in ap_read_config ()
#16 0x80aa829 in main ()
#17 0x400d31eb in __libc_start_main (main=0x80aa59c , argc=2,
argv=0xbcd4, 
init=0x80608c8 <_init>, fini=0x8140fdc <_fini>, rtld_fini=0x4000a610
<_dl_fini>, 
stack_end=0xbccc) at ../sysdeps/generic/libc-start.c:90


... or if it starts it dies after not too many requests with:

Program received signal SIGSEGV, Segmentation fault.
0x40100093 in _IO_vfprintf (s=0x819a5f0, format=0x40015f28 "@ %ld %ld
%ld\n", ap=0xb5ec)
at vfprintf.c:1059
1059vfprintf.c: No such file or directory.
(gdb) bt
#0  0x40100093 in _IO_vfprintf (s=0x819a5f0, format=0x40015f28 "@ %ld %ld %ld\n", 
ap=0xb5ec) at vfprintf.c:1059
#1  0x40107f47 in fprintf (stream=0x819a5f0, format=0x40015f28 "@ %ld %ld %ld\n")
at fprintf.c:32
#2  0x40014f6e in prof_dump_until ()
   from 
/home/value/apps/perl5.005_03/lib/site_perl/5.005/i686-linux/auto/Devel/DProf/DProf.so
#3  0x400153b0 in prof_mark ()

or 

Program received signal SIGSEGV, Segmentation fault.
0x4010c4af in _IO_fflush (fp=0x819a5f0) at iofflush.c:41
41  iofflush.c: No such file or directory.
(gdb) bt
#0  0x4010c4af in _IO_fflush (fp=0x819a5f0) at iofflush.c:41
#1  0x40014feb in prof_dump_until ()
   from
/home/value/apps/perl5.005_03/lib/site_perl/5.005/i686-linux/auto/Devel/DProf/DProf.so
#2  0x400153b0 in prof_mark ()
   from
/home/value/apps/perl5.005_03/lib/site_perl/5.005/i686-linux/auto/Devel/DProf/DProf.so
#3  0x4001585f in XS_DB_sub ()
   from
/home/value/apps/perl5.005_03/lib/site_perl/5.005/i686-linux/auto/Devel/DProf/DProf.so
#4  0x8114056 in Perl_pp_entersub ()
#5  0x80e03ec in perl_call_sv ()
#6  0x8118afe in Perl_sv_clear ()
#7  0x811c6a8 in Perl_sv_free ()
#8  0x8128973 in Perl_free_tmps ()
#9  0x8114e0d in Perl_pp_nextstate ()
#10 0x8140eed in Perl_runops_standard ()
#11 0x80e0401 in perl_call_sv ()
#12 0x400158df in XS_DB_sub ()
   from
/home/value/apps/perl5.005_03/lib/site_perl/5.005/i686-linux/auto/Devel/DProf/DProf.so
#13 0x8114056 in Perl_pp_entersub ()
#14 0x80e03ec in perl_call_sv ()
#15 0x808590b in perl_call_handler ()
#16 0x808525e in perl_run_stacked_handlers ()
#17 0x808400d in perl_handler ()
#18 0x809ea03 in ap_invoke_handler ()
#19 0x80b1f39 in ap_some_auth_required ()
#20 0x80b1f9c in ap_process_request ()
#21 0x80a983e in ap_child_terminate ()
#22 0x80a99cc in ap_child_terminate ()
#23 0x80a9b29 in ap_child_terminate ()
#24 0x80aa156 in ap_child_terminate ()
#25 0x80aa8e3 in main ()
#26 0x400d31eb in __libc_start_main (main=0x80aa59c , argc=2,
argv=0xbcd4, 
init=0x80608c8 <_init>, fini=0x8140fdc <_fini>, rtld_fini=0x4000a610
<_dl_fini>, 
stack_end=0xbccc) at ../sysdeps/generic/libc-start.c:90


the multiple ap_child_terminate's make it look like the -X doesn't take
effect? Or what's going on? Any clues?


 - ask

-- 
ask bjoern hansen - 
more than 70M impressions per day,