Skip Menu |

This queue is for tickets about the JavaScript CPAN distribution.

Report information
The Basics
Id: 60120
Status: open
Priority: 0/
Queue: JavaScript

People
Owner: Nobody in particular
Requestors: chrisb [...] debian.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 1.16
Fixed in: (no value)



Subject: Latest version of libmozjs breaks Javascript.pm
This bug was originally reported to Debian: http://bugs.debian.org/cgi- bin/bugreport.cgi?bug=591132 A recent rebuild of the Javascript module in Debian did not complete, because the 26-e4x.t is failing: Show quoted text
> # Failed test at t/26-e4x.t line 24. > # got: undef > # expected: '<xml>this is an E4X object</xml>' > # Looks like you failed 1 test of 2. > t/26-e4x.t ........................ > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/2 subtests
The full buildlog is available at: http://people.debian.org/~lucas/logs/2010/07/31/libjavascript-perl_1.16- 2_lsid64.buildlog Upon further investigation, I discovered that the package builds successfully with libmozjs 1.9.1.10, but not with 1.9.1.11. I can't see any changes related to E4X between the two, but you may have more idea..
On Thu Aug 05 18:11:30 2010, crispygoth wrote: Show quoted text
> Upon further investigation, I discovered that the package builds > successfully with libmozjs 1.9.1.10, but not with 1.9.1.11. I can't see > any changes related to E4X between the two, but you may have more idea..
What spidermonkey version is libmozjs 1.9.1.11 built from? /Claes
From: ntyni [...] iki.fi
On Fri Aug 06 03:08:57 2010, CLAESJAC wrote: Show quoted text
> On Thu Aug 05 18:11:30 2010, crispygoth wrote: >
> > Upon further investigation, I discovered that the package builds > > successfully with libmozjs 1.9.1.10, but not with 1.9.1.11. I can't see > > any changes related to E4X between the two, but you may have more idea..
> > What spidermonkey version is libmozjs 1.9.1.11 built from?
jsversion.h says 180 for both 1.9.1.10 and 1.9.1.11. The code comes from the mozilla-1.9.1 branch at http://hg.mozilla.org/releases/ The error in $@ after the parsing failure (test 1 of t/26-e4x.t) is XML cannot be the whole program at main line 21 in 2 I'm pretty sure the relevant change is http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d4b2224cf458 which unfortunately points to the non public bug https://bugzilla.mozilla.org/show_bug.cgi?id=568148 Background of the 'XML cannot be the whole program' error can be found at http://hg.mozilla.org/releases/mozilla-1.9.1/rev/c4ba70070012 https://bugzilla.mozilla.org/show_bug.cgi?id=375250 As I understand it, the test for basic E4X functionality got broken by a security related change that now rejects treating pure XML as valid top level JavaScript. A workaround is to change the test so that it mixes some real JavaScript code with the XML element, for example by explicitly getting the value of the object. See the attached patch which makes the test pass for us again. Alternatively, do you think this could/should be worked around in the actual code somehow? Perhaps by adding an extra call frame in the eval() as this only seems to concern top level calls? (Hm, that would probably break too many things. Apologies for my ignorance of the details.) Many thanks for your work, -- Niko Tyni (Debian Perl Group) ntyni@debian.org
Subject: 0001-Fix-E4X-test-failure-with-new-SpiderMonkey-versions.patch
From 156005a29965b6cada95af97ac53bfa16a6e5b2b Mon Sep 17 00:00:00 2001 From: Niko Tyni <ntyni@debian.org> Date: Sat, 21 Aug 2010 20:56:48 +0300 Subject: [PATCH] Fix E4X test failure with new SpiderMonkey versions As of Mozilla 1.9.1.11, a pure XML element is not treated as valid top level JavaScript but rather gets rejected with "XML cannot be the whole program". Work around this by throwing some valid JavaScript in the mix that explicitly takes the value of the object. See http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d4b2224cf458 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/c4ba70070012 https://bugzilla.mozilla.org/show_bug.cgi?id=375250 --- t/26-e4x.t | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/t/26-e4x.t b/t/26-e4x.t index de799fb..aeb9c8e 100644 --- a/t/26-e4x.t +++ b/t/26-e4x.t @@ -19,7 +19,7 @@ my $runtime = new JavaScript::Runtime(); my $context = $runtime->create_context(); my $ret = $context->eval(<<'EOP'); -<xml>this is an E4X object</xml> +(<xml>this is an E4X object</xml>).valueOf(); EOP is($ret, '<xml>this is an E4X object</xml>'); -- 1.7.1
From: ntyni [...] iki.fi
On Sat Aug 21 14:46:55 2010, ntyni@iki.fi wrote: Show quoted text
> As I understand it, the test for basic E4X functionality got broken by > a security related change that now rejects treating pure XML as valid > top level JavaScript. > > A workaround is to change the test so that it mixes some real JavaScript > code with the XML element, for example by explicitly getting the value > of the object. See the attached patch which makes the test pass for us > again. > > Alternatively, do you think this could/should be worked around in the > actual code somehow? Perhaps by adding an extra call frame in the eval() > as this only seems to concern top level calls? (Hm, that would probably > break too many things. Apologies for my ignorance of the details.)
Ping? The patch is most probably going in the next Debian stable unless you tell us it's a bad idea :) Thanks again, -- Niko Tyni ntyni@debian.org