603551 - XPC wrappers seem to treat uint as int

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Jan Honza Odvarko [:Honza] (always need-info? me)]

This bug was originally reported as Firebug issue here:
http://www.google.com/url?sa=D&q=http://code.google.com/p/fbug/issues/detail%3Fid%3D3503&usg=AFQjCNFOdui98Mdxga4gKSNt9pc8-rN9rA


The problem:
If I create a big array on a page:

var a = []
a.length = 3000000000;

an access its length field from chrome as:

win.a.length

it returns:

-1294967296

But, the maximum length allowed for an array is 4,294,967,295 

---

STR:
Run this on a web page:

var a = []; a.length = 3000000000;
var w = new XPCSafeJSObjectWrapper(a);
alert("w: " + w.length + ", a: " + a.length + ", same: " + (w.length == a.length)); // Expected: w: 3000000000, a: 3000000000, same: true
// Actual:   w: -1294967296, a: 3000000000, same: false

tested with Firefox 3.6

Works in Firefox 4.0b7pre

Honza

Comment 1

[Boris Zbarsky [:bzbarsky]]

This is a JS engine bug.  XPConnect just does a property get (which is NOT what JSOP_LENGTH does by default, apparently), and array_getProperty has this wonderful code:


771     if (id == ATOM_TO_JSID(cx->runtime->atomState.lengthAtom))
772         return IndexToValue(cx, obj->fslots[JSSLOT_ARRAY_LENGTH], vp);

Now IndexToValue takes a double; obj->fslots is a jsval*, and jsval is a signed integer typedef.  So the promotion to double happens from the signed integer representation.  So xpconnect is just handed the wrong value.

If we want to change the behavior here on 1.9.2 branch, we just need a cast here.  Do we want such a behavior change?

Comment 2

[Robert Sayre]

Is this bug present on trunk as well?

Comment 3

[Boris Zbarsky [:bzbarsky]]

No (comment 0 does say that).  This is pre-js::Value only.

Comment 4

[Jeff Walden [:Waldo]]

(In reply to comment #1)
> If we want to change the behavior here on 1.9.2 branch, we just need a cast
> here.  Do we want such a behavior change?

I think so, yes.  It seems unlikely anyone's depending on this bug, so I don't see a reason to not fix it, especially if someone in the wild and woolly world of the web has actually stumbled across it.

Comment 5

[Robert Sayre]

(In reply to comment #3)
> No (comment 0 does say that).  This is pre-js::Value only.

Sorry, read those as Firebug versions for some reason.

Comment 6

[Jeff Walden [:Waldo]]

I have the patch for this.  I think.  For whatever reason, I keep hitting a build error when I try to actually test out the patch:

../../gfx/ots/src/libmozots.a(ots.o): In function `(anonymous namespace)::ProcessGeneric(ots::OpenTypeFile*, ots::OTSStream*, unsigned char const*, unsigned long, std::vector<(anonymous namespace)::OpenTypeTable, std::allocator<(anonymous namespace)::OpenTypeTable> > const&, ots::Buffer&)':
/home/jwalden/moz/192/gfx/ots/src/ots.cc:434: undefined reference to `MOZ_Z_uncompress'
/usr/bin/ld: libxul.so: hidden symbol `MOZ_Z_deflateInit_' isn't defined
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make[4]: *** [libxul.so] Error 1

Looks like custom-zlib symbols aren't being macro-overwritten properly.  Or something.  Not sure what's up, hoping someone on IRC (or perhaps here) can prescribe a cure, if I don't end up figuring it out...

Comment 7

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

I guess this is wontfix at this point, if it's fixed from Gk2 onward.

Comment 8

[Sebastian Zartner [:sebo]]

Tested this right now on Firefox 17.0 and it returns the expected number 3000000000.
So it looks like this issue got fixed earlier.

Sebastian

Comment 9

[Boris Zbarsky [:bzbarsky]]

Yes, comment 0 said that.  This bug was all about Firefox 3.6 only.

WONTFIX, clearly.  ;)