Mike Giroux wrote:
[...]

How about a debugging routine one could call at the end of a program which
would fork, let the child process exit, then look up the bad SV info it
gets from the child's STDERR in its own state?

The parent process is a dupe of the child, of course, but hasn't exited
yet, so the bad SV should still be findable.

This assumes a platform with a "real" fork, of course.

Mike, you mean, it will fork just before the destruct phase has started? Will fork keep all the addresses the same? Sounds like an interesting idea.


So let's say this approach works. Let's use the bug report with leaking $0, that I've posted earier. There I was lucky to find a script reproducing the problem outside modperl and to minimize it to just 3 lines.

local $0 = "test"; # <== XXX: leaks scalar
my $thr = threads->new(sub { Dump $0 });
$thr->join;        # <== XXX: triggers the leak

So I've suspected $0 and with Devel::Peek, I've got:

SV = PVMG(0x81129a0) at 0x816dc10
  REFCNT = 1
  FLAGS = (GMG,SMG,pPOK)
  IV = 0
  NV = 0
  PV = 0x816e370 "test"\0
  CUR = 4
  LEN = 5
  MAGIC = 0x816e2a8
    MG_VIRTUAL = &PL_vtbl_sv
    MG_TYPE = PERL_MAGIC_sv(\0)
    MG_OBJ = 0x816dc04
    MG_LEN = 1
    MG_PTR = 0x816e2c8 "0"
  MAGIC = 0x816e2d8
    MG_VIRTUAL = &PL_vtbl_taint
    MG_TYPE = PERL_MAGIC_taint(t)
    MG_OBJ = 0x816dc1c
    MG_LEN = 2

the leakage report pointed out at sv=0x816dc1c, so I was lucky as it pointed at MG_OBJ in $0 dump.

Now if I wasn't lucky, and I didn't have that dump, having the information that sv=0x816dc1c is an MG_OBJ doesn't give me any idea which sv it belongs to.

In fact I've one more leak caused by thread's join(), which I can't reproduce with a simple script, and it seems to happen only under mp2. And I'm not quite sure how to find that needle in the hay of svs.

--
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Reply via email to