develooper Front page | perl.perl5.porters | Postings from May 2002

Re: [ID 20020513.015] Seg-fault running t/io/fs.t under Devel::DProf

Thread Previous | Thread Next
From:
Sam Tregar
Date:
May 14, 2002 12:15
Subject:
Re: [ID 20020513.015] Seg-fault running t/io/fs.t under Devel::DProf
Message ID:
Pine.LNX.4.44.0205141452180.20718-100000@localhost.localdomain
On Mon, 13 May 2002, Sam Tregar wrote:

> And PL_DBsub is just a funny name for $DB::sub, I think.  And $DB::sub is
> some kind of funny dual-var that's supposed to have both the name of the
> sub and its address.

Wrong, me.  It is a dual-var, but I'm pretty sure I don't know what it
contains.  The PV side always has the same number in it ("135747668").
The IV side has the address of the currently executing CV, until it
doesn't and I get the seg-fault.

Actually, the PV side is in some kind of a quantum state.  If I never do a
SvPV_nolen() on it for debugging purposes then it contains 0 when the
crash occurs.  If I look at it at all then it gets the value "135747668"
and never changes.  I'm guessing that means that the PV side is irrelevent
to Devel::DProf - I can't find a place where it is used, anyway.  That
begs the question - what is DBG_SUB supposed to do then?  It prints the PV
side as a debugging aid.

I think the weirdness in PL_DBsub has something to do with Devel::DProf
turning on PERLDBf_NONAME in PL_perldb.  This flag is documented as:

  #define PERLDBf_NONAME   0x40  /* For _SUB: no name of the subr */

Which makes exactly no sense to me.  The effect of PERLDBf_NONAME is to
cause PERLDB_SUB_NN to be true.  This alters the way that PL_DBsub is
setup, I think.

Can anyone throw me a line?  Is it possible that no one in all of p5p-dom
understands how Devel::DProf works?

-sam



Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About