Front page | perl.perl5.porters |
Postings from August 2011
Fwd: 1edc89 [perl #xxxxx] <$fh> hangs on a glob copy (Re: Nominations for 5.14.2)
Thread Previous
|
Thread Next
From:
Father Chrysostomos
Date:
August 28, 2011 12:42
Subject:
Fwd: 1edc89 [perl #xxxxx] <$fh> hangs on a glob copy (Re: Nominations for 5.14.2)
Message ID:
FF094EF8-DB41-477B-9455-A80F60888619@cpan.org
Oops. I was going to reply to one issue, so I changed the subject. Then I changed my mind and replied to several, without changing the subject back. Now there’s junk in RT.
Begin forwarded message:
> On Aug 28, 2011, at 10:26 AM, Jesse Vincent wrote:
>
>>> 71edc89 [perl #92258] <$fh> hangs on a glob copy
>>
>> Zefram feels that this issues is too contrived to justify any backport
>>
>> Also, the new behavior doesn't match the pre-broken behavior
>
> Actually it does.
>
>>
>> # 5.12 (osx)
>> (blead=10781 pod/) extracto ~/git/perl$ perl -e "open FILE, '<', \*STDIN or die; print <FILE>;"
>> ^C
>> # 5.10 (osx)
>> 130 (blead=10781 pod/) extracto ~/git/perl$ perl5.10 -e "open FILE, '<', \*STDIN or die; print <FILE>;"
>> *main::STD
>
> 5.10 is what broke it originally. What you are seeing there is memory corruption. What happened to the IN in STDIN?
>
> $ perl5.10.1 -le "open FILE, '<', \*a::a or die; print <FILE>;"
> *a::a F_
>
> That one’s reading past the glob name into random memory.
>
>>
>> # blead
>> (blead=10781 pod/) extracto ~/git/perl$ ./perl -e "open FILE, '<', \*STDIN or die; print <FILE>;"
>> Died at -e line 1.
>
> Same in 5.8.
>
> But your one-liner doesn’t trigger the exact bug that 71edc89 is fixing.
>
> Your one-liner is fixed in 5.14:
> $ perl5.14.0 -e "open FILE, '<', \*STDIN or die; print <FILE>;"
>
> But glob copies were missed:
> $ perl5.14.0 -e 'open FILE, "<", \($f=*STDIN) or die; print <FILE>;'
> ^C
>
> Both one-liners behave the same way in all previous versions.
>
>>> These two go together, as the first one only partially fixed the bug:
>>>
>>> d34a666 [perl #91880] $_ refcounting problems in @INC filters
>>> 339c6c6 Follow-up to d34a6664
>>>
>> Zefram doesn't feel like this sounds serious enough for a backport
>>
>> Hugo is concerned by the lack of connection between the patch and the writuep. In particular, it is unclear what the temp fiddling is trying to do, and whether it's doing it right.
>
> The ‘whether it’s doing it right’ part makes me laugh. Several parts of the perl core weren’t ‘doing it right’, resulting in some of the bugs I’ve fixed lately.
>
> In this particular case, that patch turns off the temp flag to avoid perpetuating an existing bug: pp_return and pp_leavesub return as-is anything marked TEMP, instead of copying it the way they are supposed to.
>
> Later in blead I fixed that return bug and removed the SvTEMP_off that that patch added.
>
> It could also be backported without the SvTEMP_off, and with some of the tests removed.
>
>>> These four need some explanation:
>>
>>> a991bd3 Make Storable freeze COWs properly (depends on 3e)
>>
>> We don't feel that this is significant enough to backport.
>>
>>> d5c6c69 Fix a Storable test to work in 5.8.9- (if you backport a9, you need this to maintain consistency)
>>
>> No reason to backport on the merits - fixes the tests on ancient versions
>
> To clarify: The test in a9 relies on the bug that 3e fixes. So 3e depends on d5 iff a9 is backported.
>
>>
>>> fa819c1 Make SvIsCOW honest about globs
>>> 3e89ba1 Make Internals::SvREADONLY smarter (depends on fa)
>>
>> Zefram has some issues with 3e and wants time to evaluate it before 5.16. Because of that, this batch of four Storable-related patches probably should _not_ be backported for now.
>>
>> Again, I'm sorry for the horrific delay in getting this sorted out. I know a couple of our "Don't backport this" items have already been backported. The disposition of those items should likely be discussed on p5p.
>>
>> Best,
>> Jesse
>
Thread Previous
|
Thread Next