Closed Bug 233483 Opened 21 years ago Closed 20 years ago

crash when i'm trying to get specific Array asString [@ MarkSharpObjects]

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: 1, Assigned: timeless)

References

Details

(4 keywords)

Crash Data

Attachments

(5 files)

Test case of Array.toString() of DOM object array
705 bytes, text/html
Details
handle null prop
3.02 KB, patch
brendan
: review+
brendan
: approval-aviary+
brendan
: approval1.7.5+
Details | Diff | Splinter Review
diff -w version of last attachment
1.76 KB, patch
Details | Diff | Splinter Review
js1_5/Regress/regress-233483.js
2.61 KB, text/plain
Details
js1_5/Regress/regress-233483-2.js
3.00 KB, text/plain
Details 
User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.6) Gecko/20040113

<HTML>
<HEAD>
<TITLE>Test</TITLE>
<SCRIPT>
window.onload=onLoad;

function onLoad() {
  var a=new Array();
  for (var pe=document.getElementById("test");pe;pe=pe.parentNode)
   {a[a.length]=pe;}
  var s=a.toString();
}

</SCRIPT>
</HEAD>
<BODY>
 <FORM>
  <table>
   <tbody>
    <tr>
     <td>
      <input id="test" value="1232">
     </td>
    </tr>
   </tbody>
  </table> 
 </FORM>
</BODY>
</HTML>

Reproducible: Always
Steps to Reproduce:
1.open html included in details
2.
3.

Actual Results:  
crash

Expected Results:  
convert array to string
can reproduce with:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
and
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040208
Firebird/0.8.0+ (stipe)
Comfirmed with 2004021008-trunk/Win-2K.
Array.toString() on DOM object array caused Mozilla crash.
Array[i].toString() has no problem.
This is not "onLoad" specicic problem.
My test case, which is slightly changed from reporter's sample, is "onClick"
case.
Does this still hapen on a current nightly?
WFM LInux 2004030208
Mozilla 2004030607-trunk/Win-2K still crashes with attachment 141091 [details].

Please note that crash does not occur on first and following 10 times alert loop
for toString() for each DOM object, a[x].toString(), and crash occrus after last
alert of "Now request s=a.toString()" in test case.
See JavaScript source of attachment 141091 [details].

Reproduced crash with testcase, same as above comment. Win2000 SP4, Mozilla/5.0
(Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040316.

Talkback incident ID: TB8389Z
Keywords: crash, talkbackid
Whiteboard: TB8389Z
 0x027ea97f
MarkSharpObjects [/mozilla/js/src/jsobj.c, line 415]
MarkSharpObjects [/mozilla/js/src/jsobj.c, line 418]
MarkSharpObjects [/mozilla/js/src/jsobj.c, line 418]
js_EnterSharpObject [/mozilla/js/src/jsobj.c, line 505]
array_join_sub [/mozilla/js/src/jsarray.c, line 341]
array_toString [/mozilla/js/src/jsarray.c, line 517]
js_Invoke [/mozilla/js/src/jsinterp.c, line 943]
js_Interpret [/mozilla/js/src/jsinterp.c, line 2963]
js_Invoke [/mozilla/js/src/jsinterp.c, line 959]
js_InternalInvoke [/mozilla/js/src/jsinterp.c, line 1036]
JS_CallFunctionValue [/mozilla/js/src/jsapi.c, line 3591]
nsJSContext::CallEventHandler [/mozilla/dom/src/base/nsJSEnvironment.cpp, line 1269]
nsJSEventListener::HandleEvent [/mozilla/dom/src/events/nsJSEventListener.cpp,
line 181]
nsEventListenerManager::HandleEventSubType
[/mozilla/content/events/src/nsEventListenerManager.cpp, line 1435]
nsEventListenerManager::HandleEvent
[/mozilla/content/events/src/nsEventListenerManager.cpp, line 1512]
nsGenericElement::HandleDOMEvent
[/mozilla/content/base/src/nsGenericElement.cpp, line 1959]
nsHTMLInputElement::HandleDOMEvent
[/mozilla/content/html/content/src/nsHTMLInputElement.cpp, line 1399]
PresShell::HandleEventInternal [/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6019]
PresShell::HandleEventWithTarget [/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5973]
nsEventStateManager::CheckForAndDispatchClick
[/mozilla/content/events/src/nsEventStateManager.cpp, line 2860]
nsEventStateManager::PostHandleEvent
[/mozilla/content/events/src/nsEventStateManager.cpp, line 1871]
PresShell::HandleEventInternal [/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6072]
PresShell::HandleEvent [/mozilla/layout/html/base/src/nsPresShell.cpp, line 5942]
nsViewManager::HandleEvent [/mozilla/view/src/nsViewManager.cpp, line 2281]
nsViewManager::DispatchEvent [/mozilla/view/src/nsViewManager.cpp, line 2025]
HandleEvent [/mozilla/view/src/nsView.cpp, line 79]
nsWindow::DispatchEvent [/mozilla/widget/src/windows/nsWindow.cpp, line 1068]
nsWindow::DispatchWindowEvent [/mozilla/widget/src/windows/nsWindow.cpp, line 1085]
nsWindow::DispatchMouseEvent [/mozilla/widget/src/windows/nsWindow.cpp, line 5225]
ChildWindow::DispatchMouseEvent [/mozilla/widget/src/windows/nsWindow.cpp, line
5478]
nsWindow::ProcessMessage [/mozilla/widget/src/windows/nsWindow.cpp, line 4063]
nsWindow::WindowProc [/mozilla/widget/src/windows/nsWindow.cpp, line 1347]
USER32.dll + 0x2a2d0 (0x77e3a2d0)
USER32.dll + 0x45e5 (0x77e145e5)
USER32.dll + 0xa816 (0x77e1a816)
nsAppShellService::Run [/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line 524]
main1 [/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1308]
main [/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1712]
WinMain [/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1734]
WinMainCRTStartup()
KERNEL32.DLL + 0x287e7 (0x7c5987e7)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: talkbackid
Whiteboard: TB8389Z
Do we know this is a JS engine bug?  How about a reduced testcase that crashes
the xpcshell or the standalone js shell?

/be
in my case, and i hope this is the right crash,
Code of interest is:

/*@line 63 -- next line is 63*/
    var trace = ((function trace(args) {maybeBreak();function toArray(ary) {var 
o = new trace.Array(), i;for (i = 0; i < ary.length; ++i) {
/*@line 65 -- next line is 65*/
o[i] = ary[i];}return o;}function stack() {try {var stackArray = [];var Stack = 
Components.stack.caller.caller;while (Stack) {stackArray.push(Stack.toString
());Stack = Stack.caller;}} catch (e) {}return stackArray;}logger("trace", 5, 
args.callee.name + "(" + toArray(args) + "){/*" + stack().join("\n") + "*/
\r\n");}));
/*@line 67 -- next line is 67*/
    trace.Array = Array;

+	cx->fp->script	0x00000000 {code=??? length=??? main=??? ...}
	JSScript *
+	cx->fp->down->script->filename
	0x0a35a7fd "file:///C:/DOCUME~1/scott/LOCALS~1/Temp/CenzicHailstorm/Cenz
icHailstorm_Temp_32.js"	const char *
	cx->fp->down->script->lineno	63	unsigned int
+	cx->fp->down->down->script->filename
	0x0a35a7fd "file:///C:/DOCUME~1/scott/LOCALS~1/Temp/CenzicHailstorm/Cenz
icHailstorm_Temp_32.js"	const char *
	cx->fp->down->down->script->lineno	1637	unsigned int
+	cx->fp->down->down->down->script->filename
	0x0a35a7fd "file:///C:/DOCUME~1/scott/LOCALS~1/Temp/CenzicHailstorm/Cenz
icHailstorm_Temp_32.js"	const char *
	cx->fp->down->down->down->script->lineno	1603	unsigned int
+	cx->fp->down->down->down->down->script->filename
	0x0a35a7fd "file:///C:/DOCUME~1/scott/LOCALS~1/Temp/CenzicHailstorm/Cenz
icHailstorm_Temp_32.js"	const char *
	cx->fp->down->down->down->down->script->lineno	3211	unsigned int
+	cx->fp->down->down->down->down->down->script->filename
	0x024bd9ad "chrome://global/content/bindings/tabbrowser.xml"	const 
char *
	cx->fp->down->down->down->down->down->script->lineno	192
	unsigned int
+	cx->fp->down->down->down->down->down->down->script	0x00000000 
{code=??? length=??? main=??? ...}	JSScript *

 	01c04b49()	
    /* Get the number of properties to enumerate. */
    if (!OBJ_ENUMERATE(cx, obj, JSENUMERATE_INIT, &iter_state, &num_properties))

+	&iter_state	0x0012eea4	long *
+	&num_properties	0x0012eea0	long *
	JSENUMERATE_INIT	0	int
+	cx	0x01c04b18 {links={next=0x01beca98 {next=0x01be9dd0 
{next=0x01d5e4c8 prev=0x01beca98 } prev=0x01c04b18 {next=0x01beca98 
prev=0x01bf7768 } } prev=0x01bf7768 {next=0x01c04b18 {next=0x01beca98 
prev=0x01bf7768 } prev=0x01b83210 {next=0x01bf7768 prev=0x01b26fe8 } } } 
interpLevel=2 stackLimit=714180 ...}	JSContext *
	i	29379352	long
	id	1240804	long
	iter_state	0	long
	num_properties	12340501	long
+	obj	0x01c04b18 {map=0x01beca98 {nrefs=29269456 ops=0x01c04b18 
{newObjectMap=0x01beca98 destroyObjectMap=0x01bf7768 
lookupProperty=0x00000002 ...} nslots=0 ...} slots=0x01bf7768 }	JSObject *

 	js3250.dll!JS_Enumerate(JSContext * cx=0x01c04b18, JSObject * 
obj=0x01c04b18)  Line 2757 + 0x21	C
 	js3250.dll!MarkSharpObjects(JSContext * cx=0x01c04b18, JSObject * 
obj=0x01c04b18, JSIdArray * * idap=0x00000000)  Line 414 + 0x9	C
 	js3250.dll!MarkSharpObjects(JSContext * cx=0x01c04b18, JSObject * 
obj=0x0a0a65c0, JSIdArray * * idap=0x00000000)  Line 453 + 0x14	C
 	js3250.dll!MarkSharpObjects(JSContext * cx=0x0a0a65c0, JSObject * 
obj=0x028f14b8, JSIdArray * * idap=0x00000000)  Line 453 + 0x14	C
 	js3250.dll!MarkSharpObjects(JSContext * cx=0x028f14b8, JSObject * 
obj=0x028f1d70, JSIdArray * * idap=0x00000000)  Line 453 + 0x14	C
 	js3250.dll!MarkSharpObjects(JSContext * cx=0x028f1d70, JSObject * 
obj=0x02861e30, JSIdArray * * idap=0x00000000)  Line 453 + 0x14	C
 	js3250.dll!MarkSharpObjects(JSContext * cx=0x02861e30, JSObject * 
obj=0x0263eac0, JSIdArray * * idap=0x00000000)  Line 453 + 0x14	C
 	js3250.dll!MarkSharpObjects(JSContext * cx=0x0263eac0, JSObject * 
obj=0x01b57118, JSIdArray * * idap=0x00000000)  Line 453 + 0x14	C
 	js3250.dll!MarkSharpObjects(JSContext * cx=0x01b57118, JSObject * 
obj=0x0a012e28, JSIdArray * * idap=0x00000000)  Line 453 + 0x14	C
 	js3250.dll!MarkSharpObjects(JSContext * cx=0x0a012e28, JSObject * 
obj=0x0a012580, JSIdArray * * idap=0x00000000)  Line 453 + 0x14	C
 	js3250.dll!MarkSharpObjects(JSContext * cx=0x0a012580, JSObject * 
obj=0x02a6eec8, JSIdArray * * idap=0x00000000)  Line 453 + 0x14	C
 	js3250.dll!MarkSharpObjects(JSContext * cx=0x02a6eec8, JSObject * 
obj=0x02b64938, JSIdArray * * idap=0x00000000)  Line 453 + 0x14	C
 	js3250.dll!MarkSharpObjects(JSContext * cx=0x02b64938, JSObject * 
obj=0x0a0a8ca8, JSIdArray * * idap=0x00000000)  Line 453 + 0x14	C
 	js3250.dll!MarkSharpObjects(JSContext * cx=0x0a0a8ca8, JSObject * 
obj=0x0a0a8d10, JSIdArray * * idap=0x0012f224)  Line 453 + 0x14	C
>	js3250.dll!js_EnterSharpObject(JSContext * cx=0x00000000, JSObject * 
obj=0x0a0a8d10, JSIdArray * * idap=0x00000000, unsigned short * * 
sp=0x0012f260)  Line 504 + 0xd	C
 	js3250.dll!array_join_sub(JSContext * cx=0x01c04b18, JSObject * 
obj=0x0a0a8d10, JSString * sep=0x00beb304, int literalize=0, long * 
rval=0x0012f2c8, int localeString=0)  Line 340 + 0x17	C
 	js3250.dll!array_toString(JSContext * cx=0x01c04b18, JSObject * 
obj=0x0a0a8d10, unsigned int argc=0, long * argv=0x0a188264, long * 
rval=0x0012f2c8)  Line 516 + 0x23	C
 	js3250.dll!js_Invoke(JSContext * cx=0x02b273ac, unsigned int argc=0, 
unsigned int flags=1240932)  Line 941 + 0x11	C
 	js3250.dll!js_InternalInvoke(JSContext * cx=0x0a188254, JSObject * 
obj=0x0a0a8d10, long fval=28668520, unsigned int flags=0, unsigned int argc=0, 
long * argv=0x00000000, long * rval=0x0012f420)  Line 1035 + 0xe	C
 	js3250.dll!js_TryMethod(JSContext * cx=0x01c04b18, JSObject * 
obj=0x0a0a8d10, JSAtom * atom=0x00ab6310, unsigned int argc=0, long * 
argv=0x00000000, long * rval=0x0012f420)  Line 3615 + 0x15	C
 	js3250.dll!js_DefaultValue(JSContext * cx=0x01c04b18, JSObject * 
obj=0x0a0a8d10, JSType hint=JSTYPE_VOID, long * vp=0x0012f510)  Line 3072 + 0x18
	C
 	js3250.dll!js_Interpret(JSContext * cx=0x00000000, long * 
result=0x0012ef64)  Line 2404 + 0x26	C
 	js3250.dll!js_Invoke(JSContext * cx=0x02b273ac, unsigned int argc=0, 
unsigned int flags=1240932)  Line 958 + 0xa	C
 	js3250.dll!js_Interpret(JSContext * cx=0x00000000, long * 
result=0x0012ef64)  Line 2964	C
 	js3250.dll!js_Invoke(JSContext * cx=0x02b273ac, unsigned int argc=0, 
unsigned int flags=1240932)  Line 958 + 0xa	C
 	xpc3250.dll!nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS * 
wrapper=0x00000000, unsigned short methodIndex=29612, const nsXPTMethodInfo * 
info=0x00000000, nsXPTCMiniVariant * nativeParams=0x0012ef64)  Line 1336 + 0x10
	C++
 	xpc3250.dll!nsXPCWrappedJS::CallMethod(unsigned short methodIndex=3, 
const nsXPTMethodInfo * info=0x0270cbe8, nsXPTCMiniVariant * 
params=0x0012f9b0)  Line 450	C++
 	xpcom.dll!PrepareAndDispatch(nsXPTCStubBase * self=0x02854020, unsigned 
int methodIndex=3, unsigned int * args=0x0012fa6c, unsigned int * 
stackBytesToPop=0x0012fa5c)  Line 117 + 0x12	C++
 	xpcom.dll!SharedStub()  Line 147	C++
 	appcomps.dll!00b78a87() 	
 	docshell.dll!00c81ee1() 	
 	docshell.dll!00c82461() 	
 	docshell.dll!00c82645() 	
 	docshell.dll!00c82793() 	
 	xpcom.dll!nsCOMPtr_base::assign_from_helper(const nsCOMPtr_helper & 
helper={...}, const nsID & iid={...})  Line 116 + 0xa	C++
 	necko.dll!011b4bfe() 	
 	gklayout.dll!00d79920() 	
 	gklayout.dll!00d7acc3() 	
 	xpcom.dll!nsEventQueueImpl::Release()  Line 195 + 0x10	C++
 	xpcom.dll!nsCOMPtr_base::assign_assuming_AddRef(nsISupports * 
newPtr=0x00000001)  Line 462	C++
 	gklayout.dll!00d79774() 	
 	xpcom.dll!PL_HandleEvent(PLEvent * self=0x029cb1b0)  Line 674	C
 	xpcom.dll!PL_ProcessPendingEvents(PLEventQueue * self=0x00a46bf0)  Line 
608 + 0x6	C
 	xpcom.dll!_md_EventReceiverProc(HWND__ * hwnd=0x002f031e, unsigned int 
uMsg=49699, unsigned int wParam=0, long lParam=10775536)  Line 1415	C
 	user32.dll!77d43a50() 	
 	user32.dll!77d43b1f() 	
 	user32.dll!77d43d79() 	
 	user32.dll!77d43fd4() 	
 	user32.dll!77d43ddf() 	
 	gkwidget.dll!0101940c() 	
 	appshell.dll!00c07be6() 	
 	mozilla.exe!00402c8a() 	
 	msvcr71.dll!free(void * pBlock=0x00407c0a)  Line 103 + 0x5	C
 	msvcr71.dll!free(void * pBlock=)  Line 103 + 0x5	C

Scott only loaded symbols for js/xpconnect/xpcom, we do have symbols for 
everything. our line numbers aren't necessarily current I can provide fixups if 
any are needed.

We crash fairly often because of this. Often enough that some code has two 
other implementations of trace() one which is function nop(){} and one which 
doesn't do stack crawling.

I should be able to construct an xpcshell world for this, but i'm not sure 
exactly what's so special about this crash. nor do i understand why there are 
soo many MarkSharpObjects frames in my case, as there are only 4 stack frames. 
[fwiw, this is basically tabbrowser->handleEvent->pageLoad->trace].
Attached patch handle null prop — — Splinter Review 
i spent yesterday walking around this code with dbradley.
today I looked and noticed that prop was null.
when prop is null, jsval val is undefined, so you get a nice UMR (whose value
happens to be cx).
Assignee: general → timeless
Status: NEW → ASSIGNED
Comment on attachment 164350 [details] [diff] [review]
handle null prop

shaver suggested the fix, and it seems to work.

there's probably a dom bug somewhere which is causing this null prop, and we
can try chasing that later, but this seems like a correct change.
Attachment #164350 - Flags: review?(brendan)
Summary: crash when i'm trying to get specific Array asString → crash when i'm trying to get specific Array asString [@ MarkSharpObjects]
Comment on attachment 164350 [details] [diff] [review]
handle null prop

Since delete could race with toSource, this seems like a necessary fix, but
your DOM testcase doesn't obviously use delete.  What is the id for which
OBJ_LOOKUP_PROPERTY returns a null prop, in what class of object (in a
debugger, look at

*(JSString*)((long)((JSAtom*)id)->entry.key-4)

for the id, and

*(JSClass*)(obj->slots[2]-1)

for the class).

/be
Attachment #164350 - Flags: review?(brendan)
Attachment #164350 - Flags: review+
Attachment #164350 - Flags: approval1.7.x?
Attachment #164350 - Flags: approval-aviary?
Essentially a one-line crash fix.  I'll slap a diff -w to show how minimal
shaver+timeless's patch is, in a second.

/be
Flags: blocking1.7.x?
Flags: blocking-aviary1.0?
Comment on attachment 164350 [details] [diff] [review]
handle null prop

Ben approved for aviary, I'm asserting that this is good for 1.7.x too.

/be
Attachment #164350 - Flags: approval1.7.x?
Attachment #164350 - Flags: approval1.7.x+
Attachment #164350 - Flags: approval-aviary?
Attachment #164350 - Flags: approval-aviary+
Fixed everywhere -- thanks, timeless.

/be
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Flags: blocking1.7.x?
Flags: blocking1.7.x+
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0+
Keywords: fixed-aviary1.0, fixed1.7.x, js1.5
Resolution: --- → FIXED
Depends on: 267574
Brendan and I sat down and tracked down where this missing prop comes from. We
end up in the prop == null case when enumerating the properties of an
HTMLFormElement object whose enumerate hook tells the JS engine that there's a
property named "0" (it uses the form controls index if the form control doesn't
have a name, as is the case here), but then the form element's resolve hook
doesn't return anything when "0" (or the integer 0, really) is resolved. Yet
form[0] does return the input. Fun.
No longer depends on: 267574
Depends on: 267574
WADA, with your permission this will be included in the javascript test
library.
(In reply to comment #17) 
> WADA, with your permission this will be included in the javascript test library.
Why I reject your offering?
It'll be my first contribute on Mozilla developement if you adopt.
I'm very appreciated if my simple test case will be test case for Mozilla
development. 
js1_5/Regress/regress-233483.js checked in.
(In reply to comment #17)
> Created an attachment (id=174974) [edit]
> js1_5/Regress/regress-233483.js

Bob Clary, I have questions on your test case.

In the test case, created array of "a" contains next only.
 a[0] : <First Form Element object in document]
As far as remember, result of reporter's case(=my case) before fix was as follows.
 a[0] : <Input Element>
 a[1] : <Parent object of Input Element> (= <TD>)
 a[2] : <Parent object of TD Element> (= <TR>)
  | 
 a[x] : <Form Element> (=< FORM>)
  |
 a[7] : <HTML Element> (= <HTML>)
 a[8] : <HTML Document Element>
        (Top level, then object.parentNode returned "monster")
 a[9] : monster, a[N] returns null.
        (End loop because the "monster" has no parentNode)
Main cause of crash on "a.toString()" was existence of this "monster" which
returns null for a[9].toString().

After bug fix, the "monster" was not created, and last array element became
"HTML Document element".
I feel ".parentNode" won't return "monster" anymore after bug fix.
(See comment #4. I said 10 array elements. But only 9 array elements now in my
test case.)

(Q1) Did the test case(form elemnt only in array of "a") really cause crash
before the fix?

(Q2) In creation of form elements, "ID" attribute is set to "test".
If this test case is always used in a document for this test case only, this has
no problem.
But if used with other cases, I think unique ID such as "bug +'test'" will be
required.
Is it OK?
(In reply to comment #20)

WADA, I tried to simplify the case so that it could be run without requiring an
external html document. It appeared to me that the problem was the prop == null
on the form as described in comment 16. 

The testcase crashes in Mozilla 1.6 and earlier when run in the browser from
<http://bclary.com/2004/10/03/js-tests/js-test-driver-quirks.html?test=js1_5/Regress/regress-174709.js;language=javascript>
however upon looking closer at the stack it may not be the exact same crash as
described in this bug especially since it doesn't crash in 1.7 release. The
stack in 1.6 is:

js_Interpret(JSContext * 0x029a7660, long * 0x0012f8c0) line 1935
js_Execute(JSContext * 0x029aa680, JSObject * 0x029aa680, JSScript * 0x02c4a5b8,
JSStackFrame * 0x00000000, unsigned int 0, long * 0x0012f8c0) line 1159
JS_EvaluateUCScriptForPrincipals(JSContext * 0x029a7660, JSObject * 0x029aa680,
JSPrincipals * 0x029c07b4, const unsigned short * 0x02c4b6b8, unsigned int 3218,
const char * 0x02c51a08, unsigned int 1, long * 0x0012f8c0) line 3523 + 17 bytes
nsJSContext::EvaluateString(nsJSContext * const 0x00000000, const nsAString &
{...}, void * 0x029aa680, nsIPrincipal * 0x029c07b0, const char * 0x02c51a08,
unsigned int 1, const char * 0x00e192a4 `string', nsAString & {...}, int *
0x0012f9f4) line 894 + 56 bytes
nsScriptLoader::EvaluateScript(nsScriptLoader * const 0x02734221,
nsScriptLoadRequest * 0x028b2740, const nsAFlatString & {...}) line 667
nsScriptLoader::ProcessRequest(nsScriptLoader * const 0x02734221,
nsScriptLoadRequest * 0x028b2740) line 582 + 9 bytes
nsScriptLoader::OnStreamComplete(nsScriptLoader * const 0x00000000,
nsIStreamLoader * 0x00a22560, nsISupports * 0x028b2740, unsigned int 0, unsigned
int 4294967295, const char * 0x00000000) line 900
nsStreamLoader::OnStopRequest(nsStreamLoader * const 0x028b2740, nsIRequest *
0x00b5adec, nsISupports * 0x028b2740, unsigned int 0) line 144
nsHttpChannel::OnStopRequest(nsHttpChannel * const 0x00000000, nsIRequest *
0x02beced0, nsISupports * 0x028b2740, unsigned int 0) line 3392
nsInputStreamPump::OnStateStop(nsInputStreamPump * const 0x02734221) line 499
nsInputStreamPump::OnInputStreamReady(nsInputStreamPump * const 0x02beced4,
nsIAsyncInputStream * 0x02bc5058) line 340
nsOutputStreamReadyEvent::EventHandler(PLEvent * 0x0273425c) line 117
PL_HandleEvent(PLEvent * 0x0273425c) line 672
PL_ProcessPendingEvents(PLEventQueue * 0x1002b811) line 606 + 6 bytes
_md_EventReceiverProc(HWND__ * 0x77d48808, unsigned int 0, unsigned int 1244588,
long 2010417573) line 1413
USER32! 77d70494()
USER32! 77d70494()
MOZILLA! _setargv address 0x0041180d

where

          enum_next_property:
            /* Get the next jsid to be enumerated and store it in rval. */
=>          OBJ_ENUMERATE(cx, obj, JSENUMERATE_NEXT, &iter_state, &rval);

and 

+	cx	0x029a7660
+	&iter_state	0x0012f758
	iter_state	41108001
+	obj	0x00000000
+	propobj->slots	0x00000003
+	&rval	0x0012f7d0


> 
> (Q1) Did the test case(form elemnt only in array of "a") really cause crash
> before the fix?

It crashes in Mozilla 1.6 and earlier but not 1.7 release nor firefox 1.0
release it appears.

> 
> (Q2) In creation of form elements, "ID" attribute is set to "test".

I don't think this is a problem since the document this executes in won't have
other content.

I will see if I can reproduce the stack using a closer example to the original
testcase.
Checked in, this version does reproduce the stack and does crash in 1.7 release
builds.  WADA, Thanks for the catch!
(In reply to comment #21)
> Checked in,
Sorry but I have another request to you...

The test case was made by bug opener, Alexander LAW. 
I only modified it slightly for ease of test, and merely attached it to make
problem re-creation by other people easier.
So I think "Contributor(s):" should contain him at top.
Bob, what do you think?
I have contacted Alexander but have not yet received a reply. If I can not get
permission soon, I will CVS remove these test cases from the JavaScript Test
Library and attempt to create independent tests which are not derivatives.
QA Contact: pschwartau → moz
Alexander has given his ok, and I have checked in regress-233483.js and
regress-233483-2.js with him as primary contributor.
Flags: testcase+
verified fixed.
Status: RESOLVED → VERIFIED
Crash Signature: [@ MarkSharpObjects]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: