289949 - crash in aviary builds using Linkification extension - FF10X [@ js_GC][@ js_LinkFunctionObject]

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[sairuh (rarely reading bugmail)]

reports have been coming in about crashing when using the Linkification
extension. problem is that we need reproducible test steps, as some people
cannot repro the crash.

Comment 1

[sairuh (rarely reading bugmail)]

I cannot seem to crash (so far) using the following builds:

2005040819-1.0.3 (linux)
2005041107-1.0.3 (linux)

Comment 2

[Chase Phillips]

Pushing onto our radar.  We'll set blocking once we get closer to finding the
cause of the crashes.

Comment 3

[Jouko Sipilä]

My talkback ID's:
TB4956550E, TB4956471Z, TB4956364W, TB4955681M, TB4955647Q, TB4955419Z,
TB4955396Z, TB4955142X, TB4955079G, TB4954756Q, TB4954566Y

Comment 4

[Jouko Sipilä]

The ID's in my previous post were with Linkification 0.9.19
This is with 0.9.20
TB5016308Y

0 crashes when Linkification has been uninstalled and 0 crashes with other 1.0.3
release candidates using Linkification.

To cause crash I open multiple tabs in row and click links on them while some
tabs are still loading.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050408
Firefox/1.0.3

Comment 5

[Da Dude]

The ID's:

TB5016721H
TB5016686X
TB5016530X
TB5016302G

My FF version:

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050410
Firefox/1.0.3(In reply to comment #0)

Comment 6

[Asa Dotzler [:asa]]

js_LinkFunctionObject 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsfun.c,
line 1973]
XPC_WN_JSOp_Safe_GetProperty 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1155]
js_Interpret 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 2823]
js_Invoke 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 966]
nsXPCWrappedJSClass::CallMethod 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp,
line 1339]
nsXPCWrappedJS::CallMethod 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp,
line 450]
SharedStub 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp,
line 147]
nsEventListenerManager::HandleEventSubType 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1436]
nsEventListenerManager::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1516]
GlobalWindowImpl::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp,
line 927]
nsXULDocument::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/document/src/nsXULDocument.cpp,
line 1257]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2823]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleChromeEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 3988]
GlobalWindowImpl::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp,
line 916]
DocumentViewerImpl::LoadComplete 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsDocumentViewer.cpp,
line 917]
nsDocShell::EndPageLoad 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/docshell/base/nsDocShell.cpp,
line 4602]
nsWebShell::EndPageLoad 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/docshell/base/nsWebShell.cpp,
line 760]
nsDocShell::OnStateChange 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/docshell/base/nsDocShell.cpp,
line 4536]
nsDocLoaderImpl::FireOnStateChange 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/uriloader/base/nsDocLoader.cpp,
line 1252]
nsDocLoaderImpl::doStopDocumentLoad 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/uriloader/base/nsDocLoader.cpp,
line 873]
nsDocLoaderImpl::OnStopRequest 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/uriloader/base/nsDocLoader.cpp,
line 701]
nsLoadGroup::RemoveRequest 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/netwerk/base/src/nsLoadGroup.cpp,
line 695]
imgRequestProxy::RemoveFromLoadGroup 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/modules/libpr0n/src/imgRequestProxy.cpp,
line 161]
imgRequestProxy::OnStopRequest 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/modules/libpr0n/src/imgRequestProxy.cpp,
line 448]
nsInputStreamPump::OnStateStop 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/netwerk/base/src/nsInputStreamPump.cpp,
line 499]

http://talkback-reports.mozilla.org/talkback/quicksearch.jsp?search=2&type=iid&id=4956550

Comment 7

[Asa Dotzler [:asa]]

also

js_GetSlotThreadSafe 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jslock.c,
line 554]
JS_GetPrivate 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsapi.c,
line 1999]
XPC_WN_JSOp_Safe_GetProperty 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1155]
js_Interpret 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 2823]
js_Invoke 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 966]
nsXPCWrappedJSClass::CallMethod 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp,
line 1339]
nsXPCWrappedJS::CallMethod 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp,
line 450]
SharedStub 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp,
line 147]
nsEventListenerManager::HandleEventSubType 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1436]
nsEventListenerManager::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1516]
GlobalWindowImpl::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp,
line 927]
nsXULDocument::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/document/src/nsXULDocument.cpp,
line 1257]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2823]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleChromeEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 3988]
GlobalWindowImpl::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp,
line 916]
DocumentViewerImpl::LoadComplete 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsDocumentViewer.cpp,
line 917]
nsDocShell::EndPageLoad 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/docshell/base/nsDocShell.cpp,
line 4602]
nsWebShell::EndPageLoad 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/docshell/base/nsWebShell.cpp,
line 760]
nsDocShell::OnStateChange 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/docshell/base/nsDocShell.cpp,
line 4536]
nsDocLoaderImpl::FireOnStateChange 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/uriloader/base/nsDocLoader.cpp,
line 1252]
nsDocLoaderImpl::doStopDocumentLoad 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/uriloader/base/nsDocLoader.cpp,
line 873]
nsDocLoaderImpl::OnStopRequest 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/uriloader/base/nsDocLoader.cpp,
line 701]
nsLoadGroup::RemoveRequest 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/netwerk/base/src/nsLoadGroup.cpp,
line 695]
HandleImagePLEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsImageLoadingContent.cpp,
line 582]
PL_HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/xpcom/threads/plevent.c,
line 674]
0x778b0c24
NS_HSV2RGB 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/style/src/nsCSSColorUtils.cpp,
line 299]
0x8b2175a6

Comment 8

[Marcia Knous [:marcia]]

(In reply to comment #3)
> My talkback ID's:
> TB4956550E, TB4956471Z, TB4956364W, TB4955681M, TB4955647Q, TB4955419Z,
> TB4955396Z, TB4955142X, TB4955079G, TB4954756Q, TB4954566Y

Did you have any other extensions installed besides Linkification?

Comment 9

[Jouko Sipilä]

(In reply to comment #8)
> 
> Did you have any other extensions installed besides Linkification?

Auto Copy, Adblock, FLST, BBCode, BugMeNot

Comment 10

[kaletin]

Talkback ID's:
TB5024359G
TB5024275Z

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050409
Firefox/1.0.3

Comment 11

[Jouko Sipilä]

Crashes happen also when only one tab open. Sorry, can't give any reproducable
clickpath because crashes seem pretty random. Happens mostly when browsing
different web-forums but I think that's because they have lots of links. :)

Also uninstalling all the other extensions didn't help.

Comment 12

[Da Dude]

Still crashes with:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050411
Firefox/1.0.3

ID: TB5039735Q

Comment 13

[Chase Phillips]

For those crashing with this extension (and this extension alone) against
today's nightly, could you add your Linkification configuration as a comment in
this bug as well?

Comment 14

[Johnny Stenback (:jst)]

Attachment: Fix. Prevent function object from being collected while cloning it.

This fixes a crash in the recently added code in xpconnect, and I bet it's this
crash. Brendan says r+sr+a=brendan.

Comment 15

[Johnny Stenback (:jst)]

Fixed on branches.

Comment 16

[Chase Phillips]

Moving to Core (this affects Suite, too).

Comment 17

[Chase Phillips]

blocking1.7.7+, blocking-aviary1.0.3+

Clearing blocking-aviary1.1 flag.

Comment 18

[Chase Phillips]

Comment on attachment 180534 [details] [diff] [review]
Fix. Prevent function object from being collected while cloning it.

Retroactively adding a=chase for branches.

Comment 19

[Chase Phillips]

Comment on attachment 180534 [details] [diff] [review]
Fix. Prevent function object from being collected while cloning it.

Moving this bug from Firefox/Extensions to Core/XPConnect caused jst's review+
to be lost, though his superreview+ was kept.

Comment 20

[Johnny Stenback (:jst)]

Attachment: Also prevent function clone from being collected, and fix similar problem in nsWindowWatcher's window.argument handling

Comment 21

[Johnny Stenback (:jst)]

Attachment: diff -w of the above for review.

Comment 22

[Da Dude]

TB5059822W

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050412
Firefox/1.0.3

Only crash i had so far, looks almost fixed :)

Comment 23

[Brendan Eich [:brendan]]

Comment on attachment 180596 [details] [diff] [review]
Also prevent function clone from being collected, and fix similar problem in nsWindowWatcher's window.argument handling

>-        // Call the getter function if the member is an attribute
>-        if(member->IsAttribute())
>         {
>-            jsid id;
>-            if(!JS_ValueToId(cx, idval, &id))
>-                return JS_FALSE;
>+            jsval funval = OBJECT_TO_JSVAL(funobj);

Just wondering if the extra block scope helps here -- doesn't it end right
where the containing block ends?  Could minimize the patch if so.

>@@ -443,28 +445,33 @@ NS_IMETHODIMP
> nsWindowWatcher::OpenWindow(nsIDOMWindow *aParent,
>                             const char *aUrl,
>                             const char *aName,
>                             const char *aFeatures,
>                             nsISupports *aArguments,
>                             nsIDOMWindow **_retval)
> {
>   PRUint32  argc;
>   jsval    *argv = nsnull;
>+  JSContext *cx;
>+  void *markp;

Canonical name is just mark (markp is the pointer to mark out param name in
js-land).

r/sr/a=me, thanks for fixing all this.

/be

Comment 24

[Johnny Stenback (:jst)]

(In reply to comment #23)
> Just wondering if the extra block scope helps here -- doesn't it end right
> where the containing block ends?  Could minimize the patch if so.

It's there only because you can't have two AUTO_MARK_JSVAL's in the same scope.
I'll comment on that.

Comment 25

[Johnny Stenback (:jst)]

Last change landed on the aviary and 1.7 branches.

Comment 26

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 180596 [details] [diff] [review]
Also prevent function clone from being collected, and fix similar problem in nsWindowWatcher's window.argument handling

So I can crash reliably with TOO_MUCH_GC defined, and I think it's because of
this patch.  The steps to reproduce are simply to launch with a URL on the
command line:

./firefox -P 1.0 http://www.netflix.com/

(where 1.0 is a profile name)


I crash here:

#5  <signal handler called>
#6  0xb7c30ca6 in js_GetGCThingFlags (thing=0x5b)
    at /builds/aviary1.0.1/mozilla/js/src/jsgc.c:218
#7  0xb7c3147f in js_MarkGCThing (cx=0x8185230, thing=0xdadadad8, arg=0x0)
    at /builds/aviary1.0.1/mozilla/js/src/jsgc.c:833
#8  0xb7c31d38 in js_GC (cx=0x8185230, gcflags=1)
    at /builds/aviary1.0.1/mozilla/js/src/jsgc.c:1288
#9  0xb7c322df in js_AllocGCThing (cx=0x8185230, flags=1)
    at /builds/aviary1.0.1/mozilla/js/src/jsgc.c:463
#10 0xb7c6ed21 in js_NewString (cx=0x8185230, chars=0x5b, length=23, gcflag=91)
    at /builds/aviary1.0.1/mozilla/js/src/jsstr.c:2450
#11 0xb7c6ee06 in js_NewStringCopyN (cx=0x8185230, s=0x820c2a0, n=23, gcflag=0)
    at /builds/aviary1.0.1/mozilla/js/src/jsstr.c:2561
#12 0xb7c0d4ad in JS_NewUCStringCopyN (cx=0x8185230, s=0x820c2a0, n=23)
    at /builds/aviary1.0.1/mozilla/js/src/jsapi.c:3838
#13 0xb74c053b in nsWindowWatcher::AddSupportsTojsvals (aArg=0xbfffe7a0,
    cx=0x8185230, aArgv=0x826f200)
    at
/builds/aviary1.0.1/mozilla/embedding/components/windowwatcher/src/nsWindowWatc
her.cpp:1841
#14 0xb74c0d90 in nsWindowWatcher::ConvertSupportsTojsvals (aWindow=0x0,
    aArgs=0x820c390, aArgc=0xbfffe9ac, aArgv=0xbfffe9b0, aUsedContext=0x5b,
    aMarkp=0xbfffe9b8)
    at
/builds/aviary1.0.1/mozilla/embedding/components/windowwatcher/src/nsWindowWatc
her.cpp:1759



In frame 8, acx == cx, sh == acx->stackHeaders, sh->nslots is 1, and sh->down
is null.  (In other words, this is the only JSStackHeader in the stack, which I
guess shouldn't be too surprising.)  It seems like uninitialized memory.  I'm
not sure what the protocol for js_AllocStack is (I couldn't find any
documentation), but it seems like either js_AllocStack or its caller should be
responsible for JSVAL_VOID-filling the memory in the stack in case the caller
allocates GC-things before filling in all the jsval* that js_AllocStack
allocated.

The following patch to nsWindowWatcher.cpp fixes my crash:

   jsval *argv = js_AllocStack(cx, argCount, aMarkp);
   NS_ENSURE_TRUE(argv, NS_ERROR_OUT_OF_MEMORY);

+  // We're going to allocate GC things before we fill in |argv| for
+  // real, so fill it with JSVAL_VOID so that, if the GC runs, it won't
+  // read uninitialized memory.
+  for (jsval *vp = argv, *vp_end = argv + argCount; vp < vp_end; ++vp)
+    *vp = JSVAL_VOID;
+
   if (argsArray)



But based on my understanding of js_AllocStack so far, I wonder if other
callers, like find_replen in jsstr.c, could also be problematic.  That said, I
don't yet understand what this code in js_AllocStack is supposed to do:

	fp = cx->fp;
	if (fp && fp->script && fp->spbase) {
#ifdef DEBUG
	    jsuword depthdiff = fp->script->depth * sizeof(jsval);
	    JS_ASSERT(JS_UPTRDIFF(fp->sp, fp->spbase) <= depthdiff);
	    JS_ASSERT(JS_UPTRDIFF(*markp, fp->spbase) >= depthdiff);
#endif
	    end = fp->spbase + fp->script->depth;
	    for (vp = fp->sp; vp < end; vp++)
		*vp = JSVAL_VOID;
	}

so I really can't tell when there's already JSVAL_VOID-filling should already
be happening.

Comment 27

[Brendan Eich [:brendan]]

dbaron, thanks for finding this old bug.  It's a bug in js_AllocStack -- but not
in the JSVAL_VOID-storing code that's there (that code is filling any gap
between current top of stack and end of allocated space for this frame's
operands).  The bug is that js_AllocStack doesn't clear new space that it returns.

Bug 290476 filed.

/be

Comment 28

[Mike Connor [:mconnor]]

Attachment: windowwatcher changes only for trunk

brendan's working on the xpconnect merge

Comment 29

[Mike Connor [:mconnor]]

Attachment: missed jst's changes on checkin

a=brendan over IRC

Comment 30

[Mike Connor [:mconnor]]

xpconnect changes will be done as part of bug 281988, resolving fixed.