develooper Front page | perl.perl5.porters | Postings from December 2016

Re: [perl #130318] segfault in Perl_mg_magical (mg.c:144)

Thread Previous | Thread Next
From:
demerphq
Date:
December 26, 2016 22:42
Subject:
Re: [perl #130318] segfault in Perl_mg_magical (mg.c:144)
Message ID:
CANgJU+W=HT4ZFvbAd5VnaxnuEGRo_v2K3q464YTNPPtBvCr3kg@mail.gmail.com
On 26 December 2016 at 22:44, Dave Mitchell <davem@iabyn.com> wrote:
> On Mon, Dec 26, 2016 at 10:18:05PM +0100, demerphq wrote:
>> An obvious solution to this would be to refcount the stack. However
>> even if we assume this is possible (I am doubtful), it would probably
>> be slow. I seem to recall that MS did some studies with VB and
>> refcount manipulation of stack arguments can account for 25% of run
>> time, which is why dotNet is garbage collected.
>
> But in practice large chunks of pp code mortalise the values they push on
> the stack to make them last long enough to be usable for the next op, but
> without leaking.  So we normally encounter the cost of manipulating the
> ref count anyway, with the added costs of checking/extending the mortals
> stack as well as the args stack, and pushing the SVs onto both stacks.
>
> So making the args stack ref counted would quite likely be a net
> performance gain (assuming we got rid of the now superfluous
> mortalisation), in addition to fixing all the bugs.
>
> The insanely difficult bit is that we currently have nearly 30K lines of
> code in the pp functions which all assume they can just do SP-- or SP -= n
> without worrying about what's on the stack. Or to croak with rubbish still
> in the stack, We would either have to review and modifiy *all* that code,
> or come up with a scheme whereby individual pp functions can be marked as
> "refcount ready"
>
>> My
>> understanding is it is rare to unheard of for real code to tickle
>> stack-not-refcounted bugs, it only happens when people do crazy stuff
>> that nobody would do in real code anyway.
>
> It's quite easy to tickle stack-not-refcounted issues. E.g.
>
>     @a = (1,2,3);
>     for (@a, 4) {
>         @a = ();
>         print $_;
>     }
>
> which croaks with
>
>     Use of freed value in iteration at ...
>
> or
>
>     sub f {
>         @a = ();
>         print $_[0];
>     }
>
>     @a = (1,2,3);
>     f(@a);
>
> which prints nothing, but can easily print garbage if the freed SV happens
> to get reallocated.

Ok, color me convinced. 30k lines of pp code sounds less like a
problem than all the XS code that does the same.

Do you have any insight on the other issues I mentioned?

Yves



-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

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