Closed Bug 58643 Opened 24 years ago Closed 24 years ago

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

Categories

(Core :: JavaScript Engine, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED WONTFIX

People

(Reporter: shantirao, Assigned: rogerl)

Details

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.
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')
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.
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.
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...
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.
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.
cc'ing Brendan and mccabe-
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
Fixing summary, marking WONTFIX. /be
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
Summary: JS_CompileFile works, JS_CompileFileHandle doesn't → JS requires 0 mod 2 alignment of private data structures (was JS_CompileFile works, JS_CompileFileHandle doesn't)
Marking Verified -
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.