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

Re: Padlist NULL pointer?

Thread Previous | Thread Next
From:
Father Chrysostomos
Date:
October 30, 2013 18:26
Subject:
Re: Padlist NULL pointer?
Message ID:
20131030182610.25874.qmail@lists-nntp.develooper.com
Marc Lehmann wrote:
> With your patch, it looks as it would avoid the segfault, but it would
> either leak memory (because it sets max to something lower), or share
> padlists (because it doesn't steal the actual pad). Maybe I am wrong,
> but I think removing a pad from the middle of the padlist is asking for
> trouble.

Yes, even my supposed correction is faulty. :-(

Another try:

diff -rup Coro-6.31-eL_b57-orig/Coro/State.xs Coro-6.31-eL_b57/Coro/State.xs
--- Coro-6.31-eL_b57-orig/Coro/State.xs2013-10-30 05:56:32.000000000 -0700
+++ Coro-6.31-eL_b57/Coro/State.xs2013-10-30 11:24:44.000000000 -0700
@@ -515,6 +515,9 @@ coro_derive_padlist (pTHX_ CV *cv)
   PAD *newpad;
   PADOFFSET const off = PadlistMAX (padlist) + 1;
 
+  while (!PadlistARRAY (padlist)[off-1])
+    off--;
+
   newPADLIST(newpadlist);
 #if !PERL_VERSION_ATLEAST(5,15,3)
   /* Padlists are AvREAL as of 5.15.3. See perl bug #98092 and perl commit 7d953ba. */

> I can imagine an algorithm that first tries to steal the highest existing
> pad (between cvdepth and max), or creates a new one if none exist.
> 
> A bit ugly but would work. However, I would really appreciate if somebody who
> understands the new pad system would point me at the code that actually
> creates 0-pad-ptr entries -

pad.c:padlist_store, though it’s not obvious.

> maybe a better solution is possible, a solution
> that doesn't require guessing on my side :)

PadlistMAX replaces AvMAX, and indicates how much space is allocated.
But I misdocumented it.  Perl itself doesn’t need to record the index
of the last allocated pad, since it does a null check before allocat-
ing a new one.

What Coro does is something I hadn’t even dreamed of.

> Now, if perl had a function that creates a new frash padlist for a cv, that
> would make things much easier... :)

I have been thinking about this from time to time, but I have been
hesitant, as I am not sure I understand exactly what is needed, and a
badly-designed API is no better than no API if it is unusable due to
its insufficiency.

Do you have any suggestions for what such an API would look like?


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