Front page | perl.perl5.porters |
Postings from April 2012
RE: [perl #112608] panic: sv_setpvn called with negative strlen -1
Thread Previous
|
Thread Next
From:
Steve Hay
Date:
April 26, 2012 01:19
Subject:
RE: [perl #112608] panic: sv_setpvn called with negative strlen -1
Message ID:
1B32FF956ABF414C9BCE5E487A1497E70D1E0681@ukmail02.planit.group
Father Chrysostomos via RT wrote on 2012-04-26:
> On Wed Apr 25 19:58:59 2012, public@khwilliamson.com wrote:
>> On 04/25/2012 05:15 AM, Leon Timmermans wrote:
>>> 2012/4/25 Steve Hay<perlbug-followup@perl.org>:
>>>> Running the program below with the attached utf8.txt input file
>>>> produces the following crash: panic: sv_setpvn called with negative
>>>> strlen -1 at utf8.pl line 4,<$rh> line 28. Close with partial
>>>> character at utf8.pl line 4,<$rh> line 28.
>>>>
>>>> open my $rh, '<:encoding(UTF-8)', 'utf8.txt' or die $!; open my
>>>> $wh, '>:encoding(ISO-8859-1)', 'iso88591.txt' or die $!;
>>>> #select((select($wh), $| = 1)[0]); print $wh $_ while<$rh>; close
>>>> $wh; close $rh;
>>>>
>>>> Obviously the (Greek) characters in the input file cannot be
>>>> converted to ISO-8859-1, but perl shouldn't crash.
>>>
>>> This crash only seems to happen when combining :crlf with :encoding.
>>> I suspect we need a smaller test-case to make it obvious what's
>>> really happening.
>>>
>>>> Uncommenting the select() call strangely makes the crash go away.
>>>> So does deleting any single line from the input file.
>>>
>>> Another thing that makes it go away: removing the byte order mark in
>>> your file. This is smelling fishy.
>>>
>>> Leon
>>>
>>
>> I could not get this to reproduce on my machine with blead.
>> Instead, I get messages like:
>> \x{feff}" does not map to iso-8859-1 at test.pl line 4, <$rh>
>> line
> 28.
>> "\x{039f}" does not map to iso-8859-1 at test.pl line 4, <$rh>
>> line
> 28.
>> "\x{03af}" does not map to iso-8859-1 at test.pl line 4, <$rh>
>> line
> 28.
>> "\x{03a3}" does not map to iso-8859-1 at test.pl line 4, <$rh>
>> line
> 28.
>> "\x{03c5}" does not map to iso-8859-1 at test.pl line 4, <$rh>
>> line
> 28.
>> "\x{03bd}" does not map to iso-8859-1 at test.pl line 4, <$rh>
>> line 28. ...
>> "\x{03cd}" does not map to iso-8859-1 at test.pl line 5, <$rh>
>> line
> 28.
>> "\x{03b6}" does not map to iso-8859-1 at test.pl line 5, <$rh>
>> line
> 28.
>> "\x{03b5}" does not map to iso-8859-1 at test.pl line 5, <$rh>
>> line
> 28.
>> "\x{03b9}" does not map to iso-8859-1 at test.pl line 5, <$rh>
>> line 28.
>>
>
> I get the same result on a Mac, both threaded and unthreaded.
>
> A C backtrace would help.
>
Those messages are, of course, expected given what the program is being asked to do. I get them first too, but then followed by a crash (panic).
Is it an EOL issue? (I'm running on Windows here.) Leon mentioned it only happening when :crlf was combined with :encoding. I still see the crash with
open my $rh, '<:encoding(UTF-8):crlf', 'utf8.txt' or die $!;
open my $wh, '>:encoding(ISO-8859-1):crlf', 'iso88591.txt' or die $!;
but not with
open my $rh, '<:raw:encoding(UTF-8)', 'utf8.txt' or die $!;
open my $wh, '>:raw:encoding(ISO-8859-1)', 'iso88591.txt' or die $!;
Also, when I download the utf8.txt attachment I find that it has got mangled somehow from what I uploaded: the line endings are now \r\r\n rather than the \r\n original which I uploaded. Furthermore, the program doesn't crash for me if I leave it like that -- I have to convert it back to \r\n before I see the crash again.
I will try to get a backtrace.
Thread Previous
|
Thread Next