58643 - JS requires 0 mod 2 alignment of private data structures (was JS_CompileFile works, JS_CompileFileHandle doesn't)

Status: VERIFIED WONTFIX

(Core :: JavaScript Engine, defect, P3)

Description

[Shanti Rao]

Using SpiderMonkey on Windows, compiled with VC6. Here's what happens with the 
test program included with RC2.

>js.exe perfect.js
[Application error: attempt to access address 0x00000003]

>js.exe
js>load('perfect.js')
[program runs correctly]

The load() function exported by js.c uses JS_CompileFile, whereas the other one 
uses JS_CompileFileHandle. 

As a workaround, one can replace JS_CompileFileHandle with JS_CompileFile in 
js.c. 

The error occurs in jsscan.c:301, the first time fgets() is called.

Comment 1

[Phil Schwartau]

I haven't been able to reproduce this either with the current code base
nor the RC2 release codebase. Each time, this is what I get in the JS shell:



[/d/JS_150_RC2/mozilla/js/src/WINNT4.0_DBG.OBJ] ./js ../perfect.js

A number is 'perfect' if it is equal to the sum of its
divisors (excluding itself).

The perfect numbers up to 500 are:
6 = 1 + 2 + 3
28 = 1 + 2 + 4 + 7 + 14
496 = 1 + 2 + 4 + 8 + 16 + 31 + 62 + 124 + 248
That's all.



This is the same result as if I do load('../perfect.js')

Comment 2

[Phil Schwartau]

Shanti, thank you for such a well-written bug report! However, we've looked 
at jsscan.c:301 and can't find any error. Did this line occur at the top 
of a call stack when you crashed? If so, could you put the call stack 
in this bug? Thanks. Also - are you able to reproduce this consistently?  


NOTE: I am using a filepath of "../perfect.js", since this file resides one 
      directory up from the executable. If I do 


                       >./js.exe perfect.js 



(so js.exe can't find the file), I get no output, but I do not crash. 

Comment 3

[Shanti Rao]

I got the error at jsscan.c:301 (fgets()) by running JS through a debugger. I'm 
able to reproduce this problem, but it may be that I'm compiling it with MS VC6 
on WNT. 

As I recall, NTDLL was at the top of the call stack -- presumably, the OS file 
system was causing the problem. The computer is a new dual processor workstation 
from Dell.

I notice that it doesn't work at all with Borland C, but I'll try compiling it 
with CodeWarrior or VisualAge and see what happens. Thanks for getting back to 
me! I really want to embed JS into my programs.

Comment 4

[Phil Schwartau]

A couple questions: 

1. If you are able to reproduce the crash, could you paste the stack trace
   into this bug? This is essential, especially if you can provide info 
   about the local variables at key frames in the stack. For example, if you
   can see the representation of the filepath in the local variables, please 
   add that info to the bug, too.


2. Have you copied the "perfect.js" into the same directory the executable
   is in? I assume so, since load('perfect.js') is working for you. 
   Just wondering whether we are in the case that js.exe finds the file, or not.



Thanks - we really need the stack trace info, because none of us have
been able to reproduce the problem. In fact we use the syntax
 
                       >js.exe -f filename 

all the time to run our test suite. There's another idea to try, however.
Does it make any difference if you include the "-f " before the filename?


Also, does the crash occur with any JavaScript file you yourself 
may have written? Or just "perfect.js" ? Perhaps "perfect.js" is corrupted
in some way. This may be it, actually...

Comment 5

[Shanti Rao]

The bug does not happen when compiled with CodeWarrior 4 on Win95.

It happens with or without the -f flag.

It happens for any JS file, first time the parser tries to read the file with 
fgets(). I strongly suspect that it's a compiler and OS specific problem.

I'll have a stack trace for you on Monday.

Comment 6

[Shanti Rao]

Ha!

It looks like it's byte alignment. I'm not absolutely sure, but this is 
definately something to think about. You might want to mention this in the 
tutorial.

In jsapi.h, you have:

/* A private data pointer (2-byte-aligned) can be stored as an int jsval.*/
#define JSVAL_TO_PRIVATE(v)     ((void *)((v) & ~JSVAL_INT))
#define PRIVATE_TO_JSVAL(p)     ((jsval)(p) | JSVAL_INT)

This looks like a pointer trick. What it does is offset the clasp pointer (slot 
2) by one byte. Under byte alignment, this causes the slot structure to overlap 
with another slot. Pointer values get screwed up, which leads to unpredictable 
behavior.

My default configuration used byte-aligned code. Changing it to 2 or 4 byte 
alignment fixes it. What happened is that when JS set up the initial context and 
object function pointers, it overwrote some of the its code segment. 

Incidentally, I found this out by compiling JS with Borland C++ using CodeGuard.

Comment 7

[Phil Schwartau]

cc'ing Brendan and mccabe-

Comment 8

[Brendan Eich [:brendan]]

I'm about to mark this bug WONTFIX.  We require all private-tagged pointers to 
be aligned on a 0 mod 2, or greater, boundary.  Always have, always will.  Could 
this bug morph into a doc bug?

/be

Comment 9

[Brendan Eich [:brendan]]

Fixing summary, marking WONTFIX.

/be

Comment 10

[Phil Schwartau]

Marking Verified -