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
perl-5.10.0-33733 assertion with JSON::XS-2.2 #9300
Comments
From david@davidfavor.comCreated by david@davidfavor.comJSON::XS and other XS modules fail with assertions of the form: t/02_error................perl: XS.xs:1418: decode_json: JSON::XS-2.1 tests clean with perl-5.8.8 latest and perl-5.10.0-33733. JSON::XS-2.2 tests clean with perl-5.8.8 latest and fails with all of Perl Info
|
From nospam-abuse@bloodgate.comOn Wednesday 23 April 2008 15:32:31 david@davidfavor.com wrote:
I am unsure what you now expect us (or somebody) to do. It looks like Did I misunderstood something? All the best, Tels
-- "Proctor & Gamble unveiled a new soap this week. Although it looks -- SNL |
The RT System itself - Status changed from 'new' to 'open' |
From @nwc10On Wed, Apr 23, 2008 at 06:32:31AM -0700, david @ davidfavor. com wrote:
I'm not quite sure why you consider a module that was released *after* 5.10.0 The assertion failure is due to a change in decode_json, from if (json->flags & F_MAXSIZE && SvCUR (string) > DEC_SIZE (json->flags)) to if (SvCUR (string) > json->max_size && json->max_size) It can be fixed with the appended patch. You mention "other XS modules". Which other XS modules? Nicholas Clark Inline Patch--- XS.xs~ 2008-04-05 19:14:48.000000000 +0100
+++ XS.xs 2008-04-25 12:10:22.000000000 +0100
@@ -1415,7 +1415,7 @@
SvGETMAGIC (string);
SvUPGRADE (string, SVt_PV);
- if (SvCUR (string) > json->max_size && json->max_size)
+ if (SvPOKp(string) && SvCUR (string) > json->max_size && json->max_size)
croak ("attempted decode of JSON text of %lu bytes size, but max_size is set to %lu",
(unsigned long)SvCUR (string), (unsigned long)json->max_size);
|
From schmorp@schmorp.deOn Fri, Apr 25, 2008 at 02:58:37PM +0100, Nicholas Clark <nick@ccl4.org> wrote:
Because the module works fine with 5.10.0, so it is a regression?
Both versions use SvCUR, so this change doesn't cause it, the problem was So earlier versions of the module would have run into the same problem
I saw that, too, but can't remember which ones it was. Since it doesn't Also, if SvCUR no longer works safely on scalars and I have to resort to I am happy to check any private flags, of course, but since this was never -- |
From schmorp@schmorp.deOn Fri, Apr 25, 2008 at 02:58:37PM +0100, Nicholas Clark <nick@ccl4.org> wrote:
This is especially troubling as the code goes to the expense of upgrading At least the new requirement of having to check a private flag (which -- |
From @janduboisOn Fri, 25 Apr 2008, Marc Lehmann wrote:
I don't think you should rely on SvCUR() to have any particular value if
I don't think a CPAN module should _ever_ check the private flags. They Cheers, |
From schmorp@schmorp.deOn Fri, Apr 25, 2008 at 05:20:48PM -0700, Jan Dubois <jand@activestate.com> wrote:
upgrading to a PV was always doing the right thing for me. The code in I also don't really think that SvPOK must be true to acecss SvCUR of a PV. If, of course, this is now required, I will update my modules accordingly, -- |
From @janduboisOn Fri, 25 Apr 2008, Marc Lehmann wrote:
What is the meaning of SvCUR() if your SV is just SvROK() and the PVX perl -MDevel::Peek -e "$a='foo'; $a=\$b; Dump $a" SvCUR() is supposed to return the "length of the string in the SV", The SvLEN() field however does have a meaning, even when SvPOK() isn't Cheers, |
From schmorp@schmorp.deOn Fri, Apr 25, 2008 at 10:42:57PM -0700, Jan Dubois <jand@activestate.com> wrote:
It gives me CUR:
Lots of modules upgrade to pv, grow to get some memory, and only then set
Just give me CUR.
You said there is no string in the pv, so how can it suddenly have a In any case, what I was pointing out that this simply was a regression. As I I don't think this is a singular case, though, and I see no wrong ina -- |
From @samvMarc Lehmann wrote:
Marc, A couple of things - it was pointed out on IRC that the builds have The documentation that describes that a string must be POK before you However I think there is more to this than that - I'm also a bit Sam. |
From @nwc10On Fri, Apr 25, 2008 at 05:20:48PM -0700, Jan Dubois wrote:
I believe that it is necessary if one wants to be polymorphic based on the This stepping through Perl_sv_setsv_flags for perl -T -e '$a = $^X' 3448 if (SvGMAGICAL(sstr) && (flags & SV_GMAGIC)) { SvPOK(sstr) is never going to be true, even after the mg_get(). Nicholas Clark |
From @nwc10On Sat, Apr 26, 2008 at 01:52:17AM +0200, Marc Lehmann wrote:
It's not a regression. The same code was present in 5.10.0 release (and in The assertions are only enabled if perl is built with the C pre-processor What did change was that I added quite a few assertions in various macros http://public.activestate.com/cgi-bin/perlbrowse?filename=sv.h&show_blame=Show+Annotated+File Specific changes to SvCUR() were made with changes 27328 and 29219, which Nicholas Clark |
From @nwc10On Sat, Apr 26, 2008 at 08:01:42AM +0200, Marc Lehmann wrote:
That's not what SvCUR() is about. It's direct access to the structure.
The documentation certainly needs correcting.
But it won't always contain a value that bears any relation to the length $ perl -MDevel::Peek -e '$a = "Long"; $a = 4; Dump $a' or with overloaded references: $ cat ~/test/overload.pl package String; use overload '""', sub { ${$_[0]} }; package main; use Devel::Peek; my $ref = ""; Dump $ref; print "$ref\n"; Dump $ref; __END__ (both those are 5.8.8) Nicholas Clark |
From schmorp@schmorp.deOn Fri, May 09, 2008 at 11:04:44PM +0100, Nicholas Clark <nick@ccl4.org> wrote:
I agree. It's breaking a working module when -g was specified at an
I didn't know, and, sorry to say so, but after compiler vendors worked so But then, I have personally no issue with that (fortunately, I alwyys
While we are at it, I cannot reproduce most of those memory savings. While "use POSIX;" now takes about 200K less memory. I actually get an _additional_ 0.4MB memory use for use POSIX, compared to TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND Note that perl without any modules is indeed smaller. And this is not related to POSIX: (almost) any module I load uses more ram
Apparently this was a failure (but good work, and a good idea).
I must admit I don't understand where to get the annotations from that
Not sure what the message here is. Lots of code in perl is very old, that I must admit, your mail confused me. -- |
From @obraIt looks like this argument wasn't actually a bug. Resolving. |
@obra - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#53244 (status was 'resolved')
Searchable as RT53244$
The text was updated successfully, but these errors were encountered: