Re: Debugging mod_perl
Nico Erfurth wrote: Hi, i'm creating an accounting system for my employer, the webfrontend is created with mod_perl. Today i had a big problem, and i don't know how to track it down. After changing one of my tool-modules apache segfaults on startup. So, how can i debug something like this? Are there any hooks inside of mod_perl i could use? Do i need to debug apache itself? Where could i start such debugging? Try to use:http://perl.apache.org/guide/debug.html#Using_the_Interactive_Debugger If you cannot figure out how to do it yourself read the SUPPORT file in the mod_perl distribution and follow the instructions on how to send the gdb backtrace to the list. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Debugging mod_perl
Nico Erfurth wrote: Today i had a big problem, and i don't know how to track it down. After changing one of my tool-modules apache segfaults on startup. So, how can i debug something like this? Do you know exactly what you changed? In that case, you have a small amount of code to look through for the problem. Take stuff out until it stops segfaulting. If you want some help figuring out why that part segfaults when you find it, post it here. - Perrin
Re: Debugging mod_perl with gdb
I recall someone once created a whole bunch of gdb macros for debugging perl. I've CC'd this to p5p in the hope that someone remembers. Tim. On Tue, Feb 06, 2001 at 12:32:45PM -0800, sterling wrote: If you're looking for which piece of perl code being processed, there are some gdb macros to help. If you source the .gdbinit in the root of your modperl dir you have access to a bunch of cool macros to use. In this case, curinfo will give you the current line number in your perl code. here's the macro: 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 hope that helps. sterling On Tue, 6 Feb 2001, Shane Adams wrote: Hey there - I've successfully built apache/mod_perl with full debugging. In addition, I'm running the whole setup through insure, a commercial memory leak/corruption tool. I've found a "write to a dangling pointer" when apache/mod_perl evaluates a perl section of the apache config file. My question: How do I go about attacking this problem? I only know that I'm in a Perl section due to printing out some variables somewhere at ap_read_config() to invoke_cmd(). I guess I'm trying to find out what the perl script is doing when the memory corruption occurs. Obviously if I could narrow the offending line of code (if possible) I might be able to better understand where the real bug is. Shane -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 30, 2001 5:25 PM To: AxKit Users Mailing List Cc: [EMAIL PROTECTED] Subject: (Correction) Re: Object-XML serialization [was Re: AxKit Users?] On Tue, 30 Jan 2001 [EMAIL PROTECTED] wrote: Castor (for Java, from www.exolab.com), uses an actual XML Schema for this. The advantage is that you can leverage off the fairly rich existing set of defined datatypes. Sorry, it's www.exolab.org, don't you hate that? --Chris
Re: Debugging mod_perl with gdb
"TB" == Tim Bunce [EMAIL PROTECTED] writes: TB I recall someone once created a whole bunch of gdb macros for debugging TB perl. I've CC'd this to p5p in the hope that someone remembers. In the mod_perl source tree (at least in CVS) there's a nice .gdbinit file that may be of use. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: Debugging mod_perl with gdb
Vivek Khera wrote: "TB" == Tim Bunce [EMAIL PROTECTED] writes: TB I recall someone once created a whole bunch of gdb macros for debugging TB perl. I've CC'd this to p5p in the hope that someone remembers. In the mod_perl source tree (at least in CVS) there's a nice .gdbinit file that may be of use. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/ has anyone had much exp with using Apache::DB? ive had it running once but then it borked out i havent got it running since or had time to play with it again thought i should drop the idea that this might be useful for debugging
Re: Debugging mod_perl with gdb
Hi there, On Tue, 6 Feb 2001, Shane Adams wrote: I've found a "write to a dangling pointer" when apache/mod_perl evaluates a perl section of the apache config file. My question: How do I go about attacking this problem? 1. Reduce your test case to the absolute minimum. 2. 'perldoc perldebug' 3. 'man gdb' 4. http://perl.apache.org/guide. 73, Ged.
Re: Debugging mod_perl with gdb
If you're looking for which piece of perl code being processed, there are some gdb macros to help. If you source the .gdbinit in the root of your modperl dir you have access to a bunch of cool macros to use. In this case, curinfo will give you the current line number in your perl code. here's the macro: 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 hope that helps. sterling On Tue, 6 Feb 2001, Shane Adams wrote: Hey there - I've successfully built apache/mod_perl with full debugging. In addition, I'm running the whole setup through insure, a commercial memory leak/corruption tool. I've found a "write to a dangling pointer" when apache/mod_perl evaluates a perl section of the apache config file. My question: How do I go about attacking this problem? I only know that I'm in a Perl section due to printing out some variables somewhere at ap_read_config() to invoke_cmd(). I guess I'm trying to find out what the perl script is doing when the memory corruption occurs. Obviously if I could narrow the offending line of code (if possible) I might be able to better understand where the real bug is. Shane -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 30, 2001 5:25 PM To: AxKit Users Mailing List Cc: [EMAIL PROTECTED] Subject: (Correction) Re: Object-XML serialization [was Re: AxKit Users?] On Tue, 30 Jan 2001 [EMAIL PROTECTED] wrote: Castor (for Java, from www.exolab.com), uses an actual XML Schema for this. The advantage is that you can leverage off the fairly rich existing set of defined datatypes. Sorry, it's www.exolab.org, don't you hate that? --Chris
RE: Debugging mod_perl with gdb
Title: RE: Debugging mod_perl with gdb Hey thanks. I'll try this. I tried the 'man gdb' command and it didn't help much I'm afraid... -Original Message- From: sterling [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 06, 2001 12:33 PM To: Shane Adams Cc: [EMAIL PROTECTED] Subject: Re: Debugging mod_perl with gdb If you're looking for which piece of perl code being processed, there are some gdb macros to help. If you source the .gdbinit in the root of your modperl dir you have access to a bunch of cool macros to use. In this case, curinfo will give you the current line number in your perl code. here's the macro: 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 hope that helps. sterling On Tue, 6 Feb 2001, Shane Adams wrote: Hey there - I've successfully built apache/mod_perl with full debugging. In addition, I'm running the whole setup through insure, a commercial memory leak/corruption tool. I've found a write to a dangling pointer when apache/mod_perl evaluates a perl section of the apache config file. My question: How do I go about attacking this problem? I only know that I'm in a Perl section due to printing out some variables somewhere at ap_read_config() to invoke_cmd(). I guess I'm trying to find out what the perl script is doing when the memory corruption occurs. Obviously if I could narrow the offending line of code (if possible) I might be able to better understand where the real bug is. Shane -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 30, 2001 5:25 PM To: AxKit Users Mailing List Cc: [EMAIL PROTECTED] Subject: (Correction) Re: Object-XML serialization [was Re: AxKit Users?] On Tue, 30 Jan 2001 [EMAIL PROTECTED] wrote: Castor (for Java, from www.exolab.com), uses an actual XML Schema for this. The advantage is that you can leverage off the fairly rich existing set of defined datatypes. Sorry, it's www.exolab.org, don't you hate that? --Chris
RE: Debugging mod_perl with gdb
Hi again, On Tue, 6 Feb 2001, Shane Adams wrote: I tried the 'man gdb' command and it didn't help much I'm afraid... Then why not have a look at http://www.gnu.org/manual/gdb-4.17/gdb.html I'm not a great fan of using debuggers, but as they go it's fantastic, it's really worth getting to know it - especially when you may be looking inside complex data structures, there it really shines. 73, Ged.
