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
>
