Front page | perl.perl5.porters |
Postings from April 2016
On Fri, Apr 08, 2016 at 09:42:22PM +0200, demerphq wrote:
> On 8 April 2016 at 13:06, demerphq <demerphq@gmail.com> wrote:
> > We are copying the subject string every 0 in the string. I dont know
> > why yet. Possibly because substr doesnt overallocate.
>
> This was the reason. Perl_sv_setpvn() was only overallocating 1 byte
> (for the null), and not 2 bytes which could hold the refcount.
>
> I have pushed three patches for this, the last changes SvGROW() to
> overallocate by 2 always under COW. IMO this should fix a lot of
> things, and theory should not break anything. If it turns out practice
> and theory differ we can revert bcc9f606 and go back to the more
> specific fix. Assuming we dont revert in a future commit we can
> probably cleannup a lot of calls to SvGROW, which almost always add 1
> or 2 to a base value, which would not longer be needed.
>
> commit bcc9f606509ad2fad50e16f081103451b7dc49e1
> Author: Yves Orton <demerphq@gmail.com>
> Date: Fri Apr 8 21:25:20 2016 +0200
>
> More generalized fix for #127855, overallocate in SvGROW and not
> just sv_grow()
>
> If we overallocate in SvGROW() and not just sv_grow() we can ensure
> we have more cases where we can COW. We need to ensure we always
> have room for a null and a reference count.
This is causing the breakage described in
[perl #127915] $=x~0 segfaults Perl 5.24.0-RC1-2-gde1d2c7
Basically by making SvGROW(sv,len) include a calculation involving
(len+2), the calculation can wrap for large len's, resulting in a small
or skipped realloc and trampled buffers.
I suggest for 5.24 we just revert this commit, and readdress the issue
more thoroughly afterwards. I already have SV growing on my Big List of
Things to Look At Properly Something.
--
"I do not resent criticism, even when, for the sake of emphasis,
it parts for the time with reality".
-- Winston Churchill, House of Commons, 22nd Jan 1941.
Thread Previous
|
Thread Next