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)
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.
Comment 1•24 years ago
|
||
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•24 years ago
|
||
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.
Reporter | ||
Comment 3•24 years ago
|
||
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•24 years ago
|
||
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...
Reporter | ||
Comment 5•24 years ago
|
||
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.
Reporter | ||
Comment 6•24 years ago
|
||
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 8•24 years ago
|
||
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•24 years ago
|
||
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)
You need to log in
before you can comment on or make changes to this bug.
Description
•