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
>

Reply via email to