Skip Menu |

This queue is for tickets about the JavaScript CPAN distribution.

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

People
Owner: Nobody in particular
Requestors: ntyni [...] iki.fi
Cc:
AdminCc:

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



Subject: Test failure on 32-bit architectures
Hi, the recently released JavaScript-1.04 (thanks!) is failing tests on Debian on all 32-bit architectures, including x86. The 64-bit architectures (amd64, ia64 and alpha) are OK. The test failure is actually two missing OKs from t/20-bind-class.t, tests 9 and 10 (the "Check multiple instance methods" block). There are no test failures because there's no check for $@ after the $cx1->eval() call. I added such a check, and the error string is 'o.fone is not a function at Foo line 103 in 1'. Debian currently has JS_VERSION 170. I haven't tried with other libmozjs versions yet. This is perfectly reproducible for me, and I have both 64-bit and a 32-bit installations so it's easy for me to debug this. I don't understand much about the libmozjs internals, though. So far I have found out that the corresponding js_Invoke() gets called with different arguments, but I have no idea yet what's happening. Are the tests working for you on a 32-bit host? For the record, we're tracking this as Debian bug #451774, http://bugs.debian.org/451774 . Cheers, -- Niko Tyni ntyni@iki.fi
Subject: Re: [rt.cpan.org #30828] Test failure on 32-bit architectures
Date: Sun, 18 Nov 2007 21:15:55 +0100
To: bug-JavaScript [...] rt.cpan.org
From: Claes Jakobsson <claes [...] versed.se>
Hi, On 18 nov 2007, at 21.03, ntyni@iki.fi via RT wrote: Show quoted text
> the recently released JavaScript-1.04 (thanks!) is failing tests on > Debian on all 32-bit architectures, including x86. The 64-bit > architectures (amd64, ia64 and alpha) are OK. > > The test failure is actually two missing OKs from t/20-bind-class.t, > tests 9 and 10 (the "Check multiple instance methods" block). There > are > no test failures because there's no check for $@ after the $cx1-
> >eval()
> call. > > I added such a check, and the error string is 'o.fone is not a > function > at Foo line 103 in 1'. > > Debian currently has JS_VERSION 170. I haven't tried with other > libmozjs > versions yet. > > This is perfectly reproducible for me, and I have both 64-bit and a > 32-bit installations so it's easy for me to debug this. I don't > understand much about the libmozjs internals, though. So far I have > found out that the corresponding js_Invoke() gets called with > different > arguments, but I have no idea yet what's happening. > > Are the tests working for you on a 32-bit host?
Hm... I'm developing on Mac OS X 10.5.1 (Darwin 9.1.0) on a Core Duo (32- bit) and there are no problems with those tests there against both a 1.7 and 1.6 release of SM. I also ran the tests for 1.04 on my Debian 4.0 box (Linux sovereign 2.6.8-3-686 #1 Tue Dec 5 21:26:38 UTC 2006 i686 GNU/Linux) which is a 32-bit celeron with a 1.7 release of SM built from source an they all passed. this is truly odd /claes
Subject: Re: [rt.cpan.org #30828] Test failure on 32-bit architectures
Date: Sun, 18 Nov 2007 23:12:00 +0200
To: Claes Jakobsson via RT <bug-JavaScript [...] rt.cpan.org>
From: Niko Tyni <ntyni [...] iki.fi>
On Sun, Nov 18, 2007 at 03:16:31PM -0500, Claes Jakobsson via RT wrote: Show quoted text
> I'm developing on Mac OS X 10.5.1 (Darwin 9.1.0) on a Core Duo (32- > bit) and there are no problems with those tests there against both a > 1.7 and 1.6 release of SM. > > I also ran the tests for 1.04 on my Debian 4.0 box (Linux sovereign > 2.6.8-3-686 #1 Tue Dec 5 21:26:38 UTC 2006 i686 GNU/Linux) which is a > 32-bit celeron with a 1.7 release of SM built from source an they all > passed.
FWIW, we're building with JS_THREADSAFE=1 JS_ENABLE_E4X=1 JS_UTF8=0 since that seems to be what the libmozjs package was compiled with. Does that match your configuration? Cheers, -- Niko
Subject: Re: [rt.cpan.org #30828] Test failure on 32-bit architectures
Date: Mon, 19 Nov 2007 22:42:40 +0200
To: Claes Jakobsson via RT <bug-JavaScript [...] rt.cpan.org>
From: Niko Tyni <ntyni [...] iki.fi>
On Sun, Nov 18, 2007 at 03:16:31PM -0500, Claes Jakobsson via RT wrote: Show quoted text
> > Are the tests working for you on a 32-bit host?
Show quoted text
> this is truly odd
Update: the difference is that the Debian libmozjs.so is compiled with MOZILLA_1_8_BRANCH. I can reproduce the problem with stock js-1.7.0.tar.gz and % make -f Makefile.ref JS_THREADSAFE=1 XCFLAGS=-DMOZILLA_1_8_BRANCH=1 The tests succeed when building JavaScript 1.04 with -DMOZILLA_1_8_BRANCH=1, which changes some things in <mozjs/jsapi.h>. Now we should just come up with a clean way to integrate this... Cheers, -- Niko
Subject: Re: [rt.cpan.org #30828] Test failure on 32-bit architectures
Date: Tue, 20 Nov 2007 15:13:28 +0200
To: Claes Jakobsson via RT <bug-JavaScript [...] rt.cpan.org>
From: Niko Tyni <ntyni [...] iki.fi>
On Mon, Nov 19, 2007 at 10:42:40PM +0200, Niko Tyni wrote: Show quoted text
> The tests succeed when building JavaScript 1.04 with > -DMOZILLA_1_8_BRANCH=1, which changes some things in <mozjs/jsapi.h>. > > Now we should just come up with a clean way to integrate this...
See also Debian bug #441059, http://bugs.debian.org/441059 . Cheers, -- Niko
Subject: Re: [rt.cpan.org #30828] Test failure on 32-bit architectures
Date: Tue, 20 Nov 2007 14:20:49 +0100
To: bug-JavaScript [...] rt.cpan.org
From: Claes Jakobsson <claes [...] versed.se>
Hm.. I think the sensible thing would be to interact with pkg-config on platforms that has it. The whole Makefile.PL and build process in JavaScript.pm needs a lot of fixing. As of 1.1 I'm actually thinking of bundling JS 1.7 (or later) and use that as default unless otherwise specified. Do you want commit-bit and fix all debian issues? I think checking if / etc/debian_version exists would be a good entry point for debian configuration things in Makefile.pl Cheers, Claes On 20 nov 2007, at 14.14, ntyni@iki.fi via RT wrote: Show quoted text
> > Queue: JavaScript > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=30828 > > > On Mon, Nov 19, 2007 at 10:42:40PM +0200, Niko Tyni wrote: >
>> The tests succeed when building JavaScript 1.04 with >> -DMOZILLA_1_8_BRANCH=1, which changes some things in <mozjs/jsapi.h>. >> >> Now we should just come up with a clean way to integrate this...
> > See also Debian bug #441059, http://bugs.debian.org/441059 . > > Cheers, > -- > Niko >
Subject: Re: [rt.cpan.org #30828] Test failure on 32-bit architectures
Date: Thu, 22 Nov 2007 13:02:56 +0200
To: Claes Jakobsson via RT <bug-JavaScript [...] rt.cpan.org>
From: Niko Tyni <ntyni [...] iki.fi>
On Tue, Nov 20, 2007 at 08:21:22AM -0500, Claes Jakobsson via RT wrote: Show quoted text
> I think the sensible thing would be to interact with pkg-config on > platforms that has it.
Yeah, at least for finding out the headers and the library paths. There's JS_THREADSAFE in there on Debian, but no information about the other ABI things (JS_UTF8, MOZILLA_1_8_BRANCH). I would assume that writing a small C program (autoconf?) to detect the library ABI things automatically would not be very hard. Of course testing it on the possible OS and mozjs version combinations is the hard part... Show quoted text
> The whole Makefile.PL and build process in JavaScript.pm needs a lot > of fixing. As of > 1.1 I'm actually thinking of bundling JS 1.7 (or later) and use that > as default unless > otherwise specified.
The bundling sounds overkill to me, but if it's going to reduce your support requests... Maybe just state 1.7 is the only one supported? Show quoted text
> Do you want commit-bit and fix all debian issues?
Thanks, but I'm not sure I want to get that involved, given that I'm not actually using the module myself for anything real. I'm happy to test out things, though, if you like. Show quoted text
> I think checking if /etc/debian_version exists > would be a good entry point for debian configuration things in > Makefile.pl
I'm not sure if derivatives like Ubuntu have it... In general testing for features and not versions is the way to go, but that makes for more work again, of course. Cheers, -- Niko