New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
panic: sv_setpvn called with negative strlen -1 [rt.cpan.org #76824] #12071
Comments
From @steve-m-hayCreated by @steve-m-hayRunning the program below with the attached utf8.txt input file produces open my Obviously the (Greek) characters in the input file cannot be converted The crash isn't new. I got the same result with 5.8.9. Perl Info
|
From @steve-m-hayΟί Συνένοχοι |
From @Leont2012/4/25 Steve Hay <perlbug-followup@perl.org>:
This crash only seems to happen when combining :crlf with :encoding. I
Another thing that makes it go away: removing the byte order mark in Leon |
The RT System itself - Status changed from 'new' to 'open' |
From @khwilliamsonOn 04/25/2012 05:15 AM, Leon Timmermans wrote:
I could not get this to reproduce on my machine with blead. Instead, I |
From @cpansproutOn Wed Apr 25 19:58:59 2012, public@khwilliamson.com wrote:
I get the same result on a Mac, both threaded and unthreaded. A C backtrace would help. -- Father Chrysostomos |
From @steve-m-hayFather Chrysostomos via RT wrote on 2012-04-26:
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 but not with open my 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. |
From @steve-m-hay[Reposting my last reply on rt.perl.org since my email of it seems to On Thu Apr 26 01:20:30 2012, Steve.Hay@verosoftware.com wrote:
Backtrace from current bleadperl (906024c): (In encode_method, sdone is 4294967295, hence iv is -1 in Perl_sv_setpvn) perl515.dll!Perl_sv_setpvn(interpreter * my_perl, sv * const sv, const |
From @cpansproutOn Thu Apr 26 01:20:30 2012, Steve.Hay@verosoftware.com wrote:
I should have read Leon Timmerman’s message more closely. If I use
I think your browser is trying to convert \n to \r\n when you download
I see your backtrace has Encode’s XS code in it. I will try to dig deeper. -- Father Chrysostomos |
From @cpansproutOn Thu Apr 26 08:35:07 2012, sprout wrote:
This is probably a bug in Encode. I’ve reduced it to a standalone This code in cpan/Encode/Encode.xs:encode_method: ENCODE_SET_SRC: calls sv_setpvn with 4294967295 for the length argument. Before this chunk of code is reached, sdone has a value of 1025, but src So somehow Encode is losing track of how far it is through the string. -- Father Chrysostomos |
From @cpansprout@_ = ( |
From @steve-m-haySteve Hay wrote on 2012-04-26:
Backtrace from current bleadperl (906024c): (In encode_method, sdone is 4294967295, hence iv is -1 in Perl_sv_setpvn) perl515.dll!Perl_sv_setpvn(interpreter * my_perl, sv * const sv, const char * const ptr, const unsigned int len) Line 4494 C |
From @dcollinsnbee7c57 is the first new commit sv.c: Don’t fiddle with AMAGIC in sv_bless Since overloading itself now checks whether caches are up to date, and :040000 040000 4a9679f7a036de75ae61b9dda7ebecc3bf5335ba 634b1a9b9c56600fac5f9d9e4335474d106cd95e M lib -- |
@dcollinsn - Status changed from 'open' to 'resolved' |
From bug-Encode@rt.cpan.org<URL: https://rt.cpan.org/Ticket/Display.html?id=76824 > Problem is still there also with blead perl. No crash or sv_setpvn panic anymore but valgrind show this error message: ==17627== Conditional jump or move depends on uninitialised value(s) Problem is again in this code from Encode.xs: STRLEN clen; I suspect that (SvCUR(src)-slen) is really incorrect and something like (tlen-sdone-slen) should be passed. IIRC s is pointer to first C char which is not yet processed in dst, slen is number of characters processed by last do_encode() call (in case of problems it can be just one or zero) and SvCUR(src) is length of original input string. (tlen-sdone) should be number of remaining characters in src, not processed in dst. With change (SvCUR(src)-slen) to (tlen-sdone-slen) valgrind does not show error message anymore... CCing khw, can you recheck this? |
From bug-Encode@rt.cpan.org<URL: https://rt.cpan.org/Ticket/Display.html?id=76824 > On Sat Oct 08 06:33:55 2016, PALI wrote:
The current code is wrong. The 2nd parameter to utf8n_to_uvuni() is the upper limit of how far it is permissible to look beyond the first byte of the string pointed to by the first parameter. The typical way that the core code uses to handle this type of thing is to save s as s0 upon entrance to the function, and then it's easy to get it right. In this case, one could set s0 after s is adjusted for *offset. s0 = s; before the loop. tlen has been calculated to be the number of bytes available in s0, it should be used instead of SvCUR. Because at the time of the function call, s is slen bytes behind the sequence you want to convert, adjustments have to be made. You could write. utf8n_to_uvuni(s+slen, tlen - (s + slen - s0), ... I think this is the most foolproof and maintainable method. Note that slen = tlen - sdone so pali's solution (tlen-sdone-slen) can be rewritten as tlen - sdone - (tlen -sdone) == 0 which is wrong. Another option would be to calculate and use sleft |
From bug-Encode@rt.cpan.org<URL: https://rt.cpan.org/Ticket/Display.html?id=76824 > On Uto Okt 18 15:44:49 2016, khw wrote:
I do not think this is truth. slen is always modified by do_encode() before utf8n_to_uvuni() call. And do_encode() set it to number of processed bytes.in that one do_encode() call. Not to tlen - sdone.
|
From bug-Encode@rt.cpan.org<URL: https://rt.cpan.org/Ticket/Display.html?id=76824 > Now I run all unit tests in Encode plus crash test from first post and compared (tlen-sdone-slen) and (tlen - (s + slen - s0)) values. Values are before every utf8n_to_uvuni() call exactly same. |
Migrated from rt.perl.org#112608 (status was 'resolved')
Searchable as RT112608$
The text was updated successfully, but these errors were encountered: