crash in JS Engine [@ js_IsDelegate ]

RESOLVED WORKSFORME

Status

()

Core
JavaScript Engine
P2
critical
RESOLVED WORKSFORME
17 years ago
14 years ago

People

(Reporter: Phil Schwartau, Assigned: brendan)

Tracking

({crash, js1.5})

Trunk
mozilla1.9alpha1
x86
Windows NT
crash, js1.5
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [QA note: verify any fix interactively via repeated load() ], crash signature)

Attachments

(3 attachments)

(Reporter)

Description

17 years ago
Reported by Christopher Oliver <coliver@mminternet.com>.

Load his testcase (attached below) in the debug JS shell. If you don't
crash, load it again. You may have to do this several times before crashing.
I crash after about five or six loads, guaranteed.

Note: as I recall, I wasn't able to crash by using the -f option to the
JS shell ( [JS dir]./js -f testcase). I used the load() function instead,
as described above. 

Stack trace to follow -
(Reporter)

Updated

17 years ago
Keywords: crash, js1.5, mozilla1.0
(Reporter)

Comment 1

17 years ago
Created attachment 76222 [details]
JS testcase that crashes
(Reporter)

Comment 2

17 years ago
Created attachment 76223 [details]
WinNT stack trace
(Reporter)

Comment 3

17 years ago
I've managed to reduce the testcase to this:

test();

function test()
{
  var n = 29926;

  for(var i=0; i<n; i++)
  {
    try
    {
      throw new Hi_exception(i);
    }
    catch(e)
    {
      e instanceof Hi_exception;
    }
  }

  function Hi_exception(num)
  {
    function f()
    { 
    }
  }
}


This does not crash every time; you have to load it over and over.
For convenience, here is the loop I used in the JS shell:

[ ] ./js
js> for (var i=0; i<25; i++) {print(i); load('CRASH.js')


Not many iterations were required to crash: usually less than 9,
sometimes as few as 2. However, be warned: there were times I did
not crash at all. It depends on inexplicable base conditions.

Note that I make no use of the variable |num| in the Hi_exception()
constructor, yet it seems to be necessary to crash. It also seems
to matter that it is called "num" and not "i". 

You get the idea...
(Reporter)

Comment 4

17 years ago
Typo: missing a brace above; should be

[ ] ./js
js> for (var i=0; i<25; i++) {print(i); load('CRASH.js')}
(Reporter)

Comment 5

17 years ago
Created attachment 76313 [details]
Reduced JS testcase
(Reporter)

Updated

17 years ago
Whiteboard: [QA note: verify any fix interactively via repeated load() ]
(Assignee)

Comment 6

17 years ago
Phil: purify might shed some light.  Cc'ing stephend in case his help is needed.

/be

Comment 7

17 years ago
when i crashed, map was 0x0. but as usual, I couldn't wade through macroland to 
find out if that was bad.
(Reporter)

Comment 8

17 years ago
jst ran Purify on this for me.

We crashed after loading the reduced testcase just once, but Purify
did not give any further information. All we got was the stack trace,
just as one would get in the VC++ debugger...
(Reporter)

Updated

16 years ago
Blocks: 149801
(Assignee)

Comment 9

16 years ago
Phil, is this bug still biting?  If so, any new crash data?

/be

Comment 10

16 years ago
I have been looking at this bug.  On a mac the test program fails with an out of
memory failure when trying to allocate space for a function object.  I am still
looking for a solution.
(Assignee)

Comment 11

16 years ago
How might we end up with a live object whose map pointer is null, though?  Or is
no one bug timeless (still?) seeing that?

/be

Comment 12

16 years ago
Reduced test case still causing an out of memory error on the Mac.

Comment 13

16 years ago
Running the Mac Codewarrior shell i got the following error messages


Welcome to js shell.
js>  for (var i=0; i<25; i++) {print(i); load('Macintosh HD:CRASH.js')
}
0
out of memory
1
out of memory
js>  for (var i=0; i<25; i++) {print(i); load('Macintosh HD:CRASH.js')}
out of memory
stack overflow in script
js> for (var i=0; i<25; i++) {print(i); load('Macintosh HD:CRASH.js')}
out of memory
stack overflow in script
uncaught exception: null
js> 


Welcome to js shell.
js> for (var i=0; i<25; i++) {print(i); load('Macintosh HD:CRASH.js')}
0
Macintosh HD:CRASH.js:23: out of memory
1
1: out of memory
js> for (var i=0; i<25; i++) {print(i); load('Macintosh HD:CRASH.js')}
out of memory
stack overflow in script
js> for (var i=0; i<25; i++) {print(i); load('Macintosh HD:CRASH.js')}
out of memory
stack overflow in script
uncaught exception: null
js> for (var i=0; i<25; i++) {print(i); load('Macintosh HD:CRASH.js')}
out of memory
stack overflow in script
uncaught exception: null
js> for (var i=0; i<25; i++) {print(i); load('Macintosh HD:CRASH.js')}
out of memory
stack overflow in script
uncaught exception: null
js> for (var i=0; i<25; i++) {print(i); load('Macintosh HD:CRASH.js')}
[object Error]
js> 

then an "Unmapped memory exception"

I suspect a stack overflow.  Memory allocation errors seem to be handled well as
expected but the corresponding stack overflow is not handled gracefully.

Comment 14

16 years ago
I will attempt to do some stackspace analysis using the StackSpace () function
available on the Mac

Comment 15

16 years ago
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.
Severity: normal → critical

Comment 16

15 years ago
I looked a bit at this bug.
I am under OS X 10.3 (G3)
it craches excatly at the second iteration.

it seems that an object is finalized js_FinalizeObject but still referenced in
the object graph (hence the obj2.map = null). At least, it was not reallocated
by js_AllocGCThing before being dereferenced in js_IsDelegate.
partial gdb dump :

(...)
finalizing 9c7ad8
allocating 804bb8
allocating 804c10
Assertion failure: (obj2)->map != 0, at jsobj.c:3382

Program received signal SIGABRT, Aborted.
0x90042aac in kill ()
(gdb) bt
#0  0x90042aac in kill ()
#1  0x9009ec5c in abort ()
#2  0x0000785c in JS_Assert (s=0xbecf0 "(obj2)->map != 0", file=0xbeca4
"jsobj.c", ln=3382) at jsutil.c:155
#3  0x00033be4 in js_IsDelegate (cx=0x200220, obj=0x924e88, v=10255064,
bp=0xbfffde30) at jsobj.c:3382
(...)
(gdb) frame 3
#3  0x00033be4 in js_IsDelegate (cx=0x200220, obj=0x924e88, v=10255064,
bp=0xbfffde30) at jsobj.c:3382
3382        while ((obj2 = OBJ_GET_PROTO(cx, obj2)) != NULL) {
(gdb) print obj2
$1 = (JSObject *) 0x9c7ad8


(tracing is done in the above-mentioned functions)

(this is my first bug report, any critics  -> mozilla@nraynaud.com )
(Assignee)

Comment 17

15 years ago
Full stack at the crash point would be helpful.  Also, the full stack of the GC
activation that finalizes that object.  There must be some control flow path
through the engine, involving exceptions and maybe nested functions, where the
exception object is not protected by a root such as cx->exception.

/be
Assignee: khanson → brendan
(Assignee)

Updated

14 years ago
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla1.8alpha
(Assignee)

Comment 18

14 years ago
Nicholas, is this still reproducing?

/be
(Assignee)

Comment 19

14 years ago
If no one has seen this, I'm inclined to mark it WFM -- it may have been fixed
by any number of changes in the last few years.

/be
Target Milestone: mozilla1.8alpha1 → mozilla1.9alpha

Comment 20

14 years ago
loaded the reduced test case > 1200 times in today's smopt with no crash. per
be's comments, marking wfm.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
QA Contact: pschwartau → moz
Resolution: --- → WORKSFORME
Crash Signature: [@ js_IsDelegate ]
You need to log in before you can comment on or make changes to this bug.