Hey folks,
I'm running CentOS 5.2 with a custom built apache not from Yum.
I am following instructions here
http://perl.apache.org/docs/2.0/devel/debug/c.html#Getting_the_core_File_Dumped
and here :
http://perl.apache.org/docs/2.0/devel/debug/c.html#Analyzing_Dumped_Core_Files
I have mod_perl b
> You're threaded.
Thanks
> What version of Apache and mod_perl are you running here?
httpd-2.2.10
mod_perl-2.0.4
> What configuration options are you using to build apache?
I didn't build it, and the guy who did is not in today, but we seem to
still have the config.log on-hand and it says sim
Oh, the symptoms sound very, very similar to mine!
I'll try upgrading the module - thanks!
--
“Don't eat anything you've ever seen advertised on TV”
- Michael Pollan, author of "In Defense of Food"
Unfortunately it seems we are already up to the latest and greatest :
Bundle Bundle::DBI (T/TI/TIMB/DBI-1.609.tar.gz)
Module DBI (T/TI/TIMB/DBI-1.609.tar.gz)
Any further help on slugging through this?
On Mon, Jul 13, 2009 at 8:22 PM, Alan McKay wrote:
> Oh,
ck.c:262
262 in modperl_callback.c
(gdb) curinfo
0Cannot access memory at address 0x600d
(gdb)
On Tue, Jul 14, 2009 at 9:08 AM, Alan McKay wrote:
> Unfortunately it seems we are already up to the latest and greatest :
>
> Bundle Bundle::DBI (T/TI/TIMB/DBI-1.609.tar.gz)
>
OK, not much response from the list :-(
More googling and I'm trying this now :
http://modperlbook.org/html/21-5-8-Noninteractive-Perl-Debugging-Under-mod_perl.html
Will keep y'all posted ...
--
“Don't eat anything you've ever seen advertised on TV”
- Michael Pollan, author of "In De
> I have had to debug these things before, and they're very painful! I
> usually end up commenting out half the code at a time to narrow things
> down, and it's never what I expect. Usually it's a module with a
> compiled library, i.e. not a pure-Perl module.
Well, the really crummy thing is tha
> http://modperlbook.org/html/21-5-8-Noninteractive-Perl-Debugging-Under-mod_perl.html
OK, I'm doing this, but it seems that the file it produces only ever
gets up to 7.3M and that's it.
I'm guessing it is because when httpd forks off all the children, they
do not record to this file anymore.
So
On Tue, Jul 14, 2009 at 4:56 PM, Perrin Harkins wrote:
> You might want to try mod_log_forensic to see what the request was
> that crashed it.
cool! Will look into that tomorrow (at home now)
thanks!
--
“Don't eat anything you've ever seen advertised on TV”
- Michael Pollan, author o
that
nobody seems to be able to answer :-(
I'd really like to get back to my original method of using gdb ...
On Tue, Jul 14, 2009 at 5:19 PM, Alan McKay wrote:
> On Tue, Jul 14, 2009 at 4:56 PM, Perrin Harkins wrote:
>> You might want to try mod_log_forensic to see what the reque
> Are you saying that you can't reproduce the crash by running the same
> request again then?
The crash is very spurious - no - it cannot be reproduced every time.
Which is why getting down into the gdb level would seem to be the best
way about this problem
--
“Don't eat anything you've ever s
>>> http://modperlbook.org/html/21-5-8-Noninteractive-Perl-Debugging-Under-mod_perl.html
>>
>> OK, I'm doing this, but it seems that the file it produces only ever
>> gets up to 7.3M and that's it.
OK, the reason the file only ever got to 7.3M was indeed because
apache would of course fork a bunch
Igor,
Are you familiar with how to prepare mod_perl for a proper core dump,
and then load the core dump into the debugger?
I fought through this not long ago - though was not that difficult.
http://httpd.apache.org/dev/debugging.html
http://perl.apache.org/docs/2.0/devel/debug/c.html#Analyzing_D
13 matches
Mail list logo
