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