877136 - spidermonkey fails on amd64

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[ak47izatool]

Attachment: code sample, that demonstrates x86_64 problem

User Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Firefox/17.0 (Nightly/Aurora)
Build ID: 20121120210810

Steps to reproduce:

Property creation in spidermonkey is broken on x86_64. I see some strange numbers instead of the actual values I stored with JS_DefineProperty(). I've created the sample code that works right on 32 bit OS, and fails on 64 bit. Tested on two 64 bit Ubuntu 12, one 64 bit CentOS 6.4. spidermonkey 1.8.5, both debug and release builds.


Actual results:

$ ./dp
number is: 4e-323
string is: "2.3265751512672e-310"
rval: 'one'


Expected results:

$ ./dp
number is: 8
string is: "bar string"
rval: 'one'

Comment 1

[Loic]

Your archive attached to the bug is corrupt (WinRAR fails to open it), could you attach a new one, please.

Comment 2

[ak47izatool]

Attachment: code sample, that demonstrates x86_64 problem, zip archive

Hmm, that's strange. I've just downloaded it & opened with 7zip. Reattached same in zip anyway.

Comment 3

[Boris Zbarsky [:bzbarsky]]

> 4e-323

This has the same bitwise representation as the integer 8.

Which suggests that for some reason in your case INT_TO_JSVAL(8) is producing the value 8 and not the value it should actually be producing.  What exactly does INT_TO_JSVAL expand to in your code?

> 2.3265751512672e-310

This is 0x2ad416e18040 which looks like a quite possible pointer.  So again, in your case STRING_TO_JSVAL is not doing what it should.

Comment 4

[ak47izatool]

I ran preprocessor on provided test example, and INT_TO_JSVAL is not expanded.
 if (!JS_DefineProperty(cx, global, "foo", INT_TO_JSVAL(8), JS_PropertyStub, JS_StrictPropertyStub, 0x02)) {
...
Same for STRING_TO_JSVAL. Is there any other information I can provide? Is the problem I described reproducible in your environment?

Comment 5

[Boris Zbarsky [:bzbarsky]]

OK, if it's not being expanded then it's a function.  What happens when you step into that function?  What does its implementation look like for you?

I don't have an obvious way to link your .c with a SpiderMonkey library, and it sounds like the exact library you're linking with is key here.  Certainly the problem you describe does not happen in 64-bit Linux or Mac builds of Firefox, which most definitely use SpiderMonkey and constructs like what your testcase has....

Comment 6

[ak47izatool]

Here is my gdb session:
Breakpoint 1, INT_TO_JSVAL (i=1) at jsapi.h:133
133         return IMPL_TO_JSVAL(INT32_TO_JSVAL_IMPL(i));
(gdb) step
INT32_TO_JSVAL_IMPL (i32=1) at jsval.h:594
594         l.asBits = ((uint64)(uint32)i32) | JSVAL_SHIFTED_TAG_INT32;
(gdb) bt
#0  INT32_TO_JSVAL_IMPL (i32=1) at jsval.h:594
#1  0x00002aaaaaec9765 in INT_TO_JSVAL (i=1) at jsapi.h:133
#2  0x00002aaaaaecafcd in js_InitTypedArrayClasses (cx=0x674ea0, obj=0x2aaaace03048) at jstypedarray.cpp:1596
#3  0x00002aaaaae3ab0c in js_GetClassObject (cx=0x674ea0, obj=0x2aaaace03048, key=JSProto_ArrayBuffer, objp=0x7fffffffe268) at jsobj.cpp:4216
#4  0x00002aaaaaecaf12 in js_InitTypedArrayClasses (cx=0x674ea0, obj=0x2aaaace03048) at jstypedarray.cpp:1589
#5  0x00002aaaaad379ec in JS_InitStandardClasses (cx=0x674ea0, obj=0x2aaaace03048) at jsapi.cpp:1608
#6  0x00000000004011bd in main (argc=1, argv=0x7fffffffe518) at dp.c:77
(gdb) l
589
590     static JS_ALWAYS_INLINE jsval_layout
591     INT32_TO_JSVAL_IMPL(int32 i32)
592     {
593         jsval_layout l;
594         l.asBits = ((uint64)(uint32)i32) | JSVAL_SHIFTED_TAG_INT32;
595         return l;
596     }
597

Made on debug build of spidermonkey https://ftp.mozilla.org/pub/mozilla.org/js/js185-1.0.0.tar.gz
Build options: ./configure --disable-tests --enable-static --with-system-nspr \
        --enable-threadsafe --enable-jemalloc --enable-readline --enable-debug

Comment 7

[Boris Zbarsky [:bzbarsky]]

> INT_TO_JSVAL (i=1)

That's clearly not your call.  What happens on your call?

>594         l.asBits = ((uint64)(uint32)i32) | JSVAL_SHIFTED_TAG_INT32;

This part looks right, but you should not be ending up with the results you end up with, if so.

So let's rephrase.  If you step into your first JS_DefineProperty call, what does the bit layout of the fourth argument look like once you're inside of the call?

Comment 8

[ak47izatool]

Breakpoint 2, INT_TO_JSVAL (i=8) at dp.c:87
87              if (!JS_DefineProperty(cx, global, "foo", INT_TO_JSVAL(8), JS_PropertyStub, JS_StrictPropertyStub, JSPROP_READONLY)) {
(gdb) step
JS_DefineProperty (cx=0x674ea0, obj=0x2aaaace03048, name=0x4015f1 "foo", value=..., getter=0x400d50 <JS_PropertyStub@plt>, 
    setter=0x400d00 <JS_StrictPropertyStub@plt>, attrs=2) at jsapi.cpp:3465
3465                              Valueify(setter), attrs, 0, 0);
(gdb) p value
$2 = {asBits = 8, debugView = {payload47 = 8, tag = 0}, s = {payload = {i32 = 8, u32 = 8, why = JS_SERIALIZE_NO_NODE, word = 8}}, 
  asDouble = 3.9525251667299724e-323, asPtr = 0x8}

Comment 9

[Boris Zbarsky [:bzbarsky]]

> asBits = 8

This is most definitely wrong.  What happened to JSVAL_SHIFTED_TAG_INT32?

Comment 10

[ak47izatool]

(gdb) p JSVAL_SHIFTED_TAG_INT32 
$2 = -2111062325329920

Comment 11

[Boris Zbarsky [:bzbarsky]]

That's 0xfff8800000000000, which looks like the right value.

So why did your asBits end up as "8" instead of "0xfff8800000000008"?  What was your l.asBits after line 594 from your comment 6 ran?

Comment 12

[ak47izatool]

(gdb) p l.asBits 
$1 = 18444633011384221697
(gdb) p i32
$2 = 1

Comment 13

[Boris Zbarsky [:bzbarsky]]

That's a different call to INT_TO_JSVAL.  I'm interested in your call.

Basically, what _should_ happen here is that INT_TO_JSVAL(8) should produce a jsval whose asBits is 0xfff8800000000008.  Then that should be the asBits seen inside the JS_DefineProperty.

What you see inside JS_DefineProperty is clearly not that.  So presumably something goes wrong earlier.  What you need to check is whether that's during the INT_TO_JSVAL call or after.

Note that stepping into INT_TO_JSVAL as called from js_InitTypedArrayClasses just tells you that when your spidermonkey was compiled JSVAL_SHIFTED_TAG_INT32 was set to the right value.  The question is what value _your_ .c file sees it set to.  Note that it's a macro and all, so every single INT32_TO_JSVAL_IMPL use will see whatever the macro is defined to at that point.

Comment 14

[ak47izatool]

I am unable to step into INT_TO_JSVAL() at the time of my JS_DefineProperty() call. Any suggestions?
Here is what related functions looks like after preprocessor pass:

#define JSVAL_INT_BITS 32
#define JSVAL_INT_MIN ((jsint)0x80000000)
#define JSVAL_INT_MAX ((jsint)0x7fffffff)

static __attribute__((always_inline)) __inline__ jsval
INT_TO_JSVAL(int32 i)                                                                                                                           
{                                                                                                                                               
    return ((INT32_TO_JSVAL_IMPL(i)).asBits);
}

INT32_TO_JSVAL_IMPL(int32 i)
{                                                                                                                                               
    jsval_layout l;
    l.s.tag = ((uint32)(((uint32)(0xFFFF0000)) | ((uint8)0x01)));
    l.s.payload.i32 = i;                                                                                                                        
    return l;                                                                                                                                   
}

Comment 15

[Boris Zbarsky [:bzbarsky]]

>    jsval_layout l;
>    l.s.tag = ((uint32)(((uint32)(0xFFFF0000)) | ((uint8)0x01)));
>    l.s.payload.i32 = i;      

That's what INT32_TO_JSVAL_IMPL should be if JS_BITS_PER_WORD == 32.

Are you compiling your spidermonkey as 32-bit and your .c file as 64-bit or vice versa?  Because that's the most likely explanation for what's going on here.

Comment 16

[ak47izatool]

After some time with preprocessed file, I've found #define JS_BYTES_PER_WORD 4, and I realized that I was using wrong headers of 32 bit version... Thanks for your answers, Boris, you pointed me into the right direction. Sorry for wasting your time -_-

Comment 17

[Boris Zbarsky [:bzbarsky]]

No problem.  Glad we hunted this down!