develooper Front page | perl.perl5.porters | Postings from March 2013

OP ownership, op_free and slabs

Thread Next
From:
Lukas Mai
Date:
March 1, 2013 10:03
Subject:
OP ownership, op_free and slabs
Message ID:
51307CF9.4080201@web.de
Hi,

I'm running into assertion failures with Function::Parameters on blead perl.

As far as I understand it, the problem is that I don't know how OP 
cleanup is supposed to work and who actually owns OPs. 
Function::Parameters is a keyword plugin, so it has to construct OPs 
manually. Unfortunately op_free has no documentation. I'd assumed it 
worked like this:

- Any OP I create (via newOP/new* or parse_fullexpr/parse_*) must be 
either incorporated into the "main" op tree and returned to perl (which 
becomes then responsible for freeing it), or op_free()d.

Question 1: Was this ever correct?


My current code triggers an assert in op_free:

     /* Though ops may be freed twice, freeing the op after its slab is a
        big no-no. */
     assert(!o || !o->op_slabbed || OpSLAB(o)->opslab_refcnt != ~(size_t)0);

I *think* this happens because my OPs are both explicitly registered in 
a list (which I free in a custom SAVEDESTRUCTOR) and implicitly 
registered with the current CV (via the slab system). Now when I 
croak(), my CV gets freed first (and takes down the slabbed OPs), then 
my custom destructor runs and tries to op_free() them again.

If this is true, then the fix would be to just not do anything with the 
OPs I allocate and rely on the slab code to free them later.

Question 2: Is this how slabbed OPs are supposed to be used?

Question 3: If so, what should I do with unslabbed OPs/perls? Should I 
keep my custom oplist destructor code (but #ifdef it out for slabbed 
builds)?


-- 
Lukas Mai <l.mai@web.de>

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