perlbug-followup at perl
Apr 25, 2012, 1:09 PM
Post #2 of 2
(41 views)
Permalink
|
|
[perl #112312] perl5 version 5.14.2 coredumps during perl -c
[In reply to]
|
|
On Wed Apr 25 03:38:30 2012, davem wrote:
> On Tue, Apr 24, 2012 at 02:01:45PM -0700, Father Chrysostomos via RT
wrote:
> > On Sun Apr 08 03:32:21 2012, nicholas wrote:
> > > But, I'm suspecting, that the only *real* fix to all of this mess is
> > > to
> > > garbage collect the OPs, in some fashion.
> >
> > The simplest way might be to create something like the mortals’ stack,
> > but for OPs. Or maybe a mortalop hash.
> >
> > Code that could croak can do the equivalent of SAVEFREEOP, and then
> > delete the op from the mortalop stack when everything is safe.
> >
> > Would that be as fast as a tortoise, or slower?
> >
> > Or maybe a suggestion I had earlier: a variant of SAVEFREEOP that uses
> > the savestack but returns a token (probably a stack offset) that can be
> > used to disarm the item on the savestack and turn it into a no-op:
> >
> > I32 token = SAVEFREEOP_token(o);
> > ... do something unsafe that might croak ...
> > DISARM_SAVESTACK(token);
> > op_free(o);
>
> I think another suggestion that was mooted a while ago would be to
> allocate OPs from a pool or slab, with a new pool/slab started each time
> we start compiling a new sub, and the pool in some way marked as complete
> at the end of compiling the sub. On croaking, all the OPs in the
> unfinished pools are freed. That way most code doesn't need to be
> modified.
I sort of understand that in theory, but I don’t understand it well
enough to feel confident about implementing it.
--
Father Chrysostomos
---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=112312
|
