Invalid free in t/op/write.t #11369
Comments
From @khwilliamsonThis is a bug report for perl from khw@karl.(none), This is reproducible. not ok 326 # TODO [ID 20020227.005] format bug with undefined _TOP Flags: Site configuration information for perl 5.15.0: Configured by khw at Wed May 18 13:24:20 MDT 2011. Summary of my perl5 (revision 5 version 15 subversion 0) configuration: Locally applied patches: @INC for perl 5.15.0: /home/khw/blead/lib/perl5/site_perl/5.15.0/i686-linux-thread-multi-64int-ld Environment for perl 5.15.0: PATH=/home/khw/bin:/home/khw/print/bin:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/usr/games:/home/khw/cxoffice/bin |
From @khwilliamsonGit bisect results: 37ffbfc is the first bad commit In S_doparseform(), don't force the pattern to a string. This |
From [Unknown Contact. See original ticket]Git bisect results: 37ffbfc is the first bad commit In S_doparseform(), don't force the pattern to a string. This |
|
@khwilliamson - Status changed from 'new' to 'open' |
From [email protected]On Sat, 2011-05-21 at 08:56 -0700, Karl Williamson via RT wrote:
But this is just when the test in t/op/write.t was introduced. The underlying failure is present in perl5.12.0
|
From [email protected]Created by [email protected]This is a cutdown of a failure (abort) from t/op/write.t test #331 I'm sorry I don't understand this stuff.
Perl Info |
From @iabynOn Sat, May 21, 2011 at 07:32:15PM +0100, Nicholas Clark wrote:
I'll have a look -- |
From @nwc10On Sat, May 21, 2011 at 06:09:31PM +0100, Robin Barker wrote:
Bisecting with this: #!/bin/sh It's this: commit 815f25c [perl #7391] Perl crashes with certain write() formats. Inline Patchdiff --git a/pp_ctl.c b/pp_ctl.c
index 91fc2ca..8665678 100644
--- a/pp_ctl.c
+++ b/pp_ctl.c
@@ -3573,11 +3573,20 @@ S_doparseform(pTHX_ SV *sv)
U16 *linepc = 0;
register I32 arg;
bool ischop;
+ int maxops = 2; /* FF_LINEMARK + FF_END) */
if (len == 0)
Perl_croak(aTHX_ "Null picture in formline");
- New(804, fops, (send - s)*3+10, U16); /* Almost certainly too long... */
+ /* estimate the buffer size needed */
+ for (base = s; s <= send; s++) {
+ if (*s == '\n' || *s == '@' || *s == '^')
+ maxops += 10;
+ }
+ s = base;
+ base = Nullch;
+
+ New(804, fops, maxops, U16);
fpc = fops;
if (s < send) {
@@ -3740,6 +3749,7 @@ S_doparseform(pTHX_ SV *sv)
}
*fpc++ = FF_END;
+ assert (fpc <= fops + maxops); /* ensure our buffer estimate was valid */
arg = fpc - fops;
{ /* need to jump to the next word */
int z;
Nicholas Clark |
From @cpansproutThis is a known issue (#91032) and Dave Mitchell is working on it. I’ll |
|
The RT System itself - Status changed from 'new' to 'open' |
From [email protected]This misbehaviour first appeared at The code prior to that change suggests that C<maxops += 10> should be This patch follows that suggestion and includes the previous patch from Robin |
From [email protected]0001-fix-e-formline.patchFrom d4249ec0c12855264ef8b61fa504a3d2e83dc65e Mon Sep 17 00:00:00 2001
From: Robin Barker <[email protected]>
Date: Tue, 24 May 2011 14:00:40 +0100
Subject: [PATCH] fix -e 'formline []'
The misbehavour of -e 'formline []' first appeared at
commit 815f25c6e302f84ecce02c74fa717a19d787f662
Prior to that change maxops=10+3*l (where l=length)
after than change maxops=3+10*x (for some x<l).
I think this was a transposition of 3 and 10.
This patch reverts the multiplier to 3, as well
as including the real fix for the misbehaviour
from Nicholas Clark.
---
pp_ctl.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/pp_ctl.c b/pp_ctl.c
index f86f55c..f10e8bb 100644
--- a/pp_ctl.c
+++ b/pp_ctl.c
@@ -4940,8 +4940,8 @@ S_doparseform(pTHX_ SV *sv)
/* estimate the buffer size needed */
for (base = s; s <= send; s++) {
- if (*s == '\n' || *s == '@' || *s == '^')
- maxops += 10;
+ if ( *s == '\0' || *s == '\n' || *s == '@' || *s == '^' )
+ maxops += 3;
}
s = base;
base = NULL;
--
1.7.1
|
From @iabynOn Sat, May 21, 2011 at 10:05:49PM +0100, Dave Mitchell wrote:
Now looked at and fixed. The basic problem is that when a format is compiled, it keeps indexes Frankly, pp_formline was a big mess and full of bugs and potential bombs. I've fixed many things within it with the 20 commits running between and inclusive, with the first one most closely addressing the bug in this ticket. -- |
|
@iabyn - Status changed from 'open' to 'resolved' |
From @cpansproutOn Wed May 25 12:40:13 2011, rmbarker.cpan@btinternet.com wrote:
Did you compile with -DDEBUGGING? I tried your patch and got an Assertion failed: (fpc <= fops + maxops), function S_doparseform, file I’m probably too late in responding, because I see Dave Mitchell has |
From @iabynOn Sun, May 29, 2011 at 12:54:45PM -0700, Father Chrysostomos via RT wrote:
Hang about, I'm confused now. All the failures I saw were in pp_parseform, -- |
From @iabynOn Sun, May 29, 2011 at 09:29:49PM +0100, Dave Mitchell wrote:
But regardless, Robin's patch looks successful. Can anyone see the assertion failure since my series of commits? -- |
From @cpansproutOn Tue May 31 05:56:57 2011, davem wrote:
I only got an assertion failure when I tried out Robin’s patch. So I
?
No. Nor was there one before that. |
From @iabynOn Tue, May 31, 2011 at 08:33:07AM -0700, Father Chrysostomos via RT wrote:
Ok I've looked more closely at this, and I'm happy now that the buffer Basically each of \n, @ and ^ can add up to 10 ops, while \0 can add 10 -- |
Migrated from rt.perl.org#91032 (status was 'resolved')
Searchable as RT91032$
The text was updated successfully, but these errors were encountered: