482809 - Crash [@ jsds_SyncFilter(FilterRecord*, jsdIFilter*) ] when appendFilter() called with Console2 installed

Status: VERIFIED FIXED

(Other Applications Graveyard :: Venkman JS Debugger, defect)

Description

[Michael Kraft [:morac]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090311 Minefield/3.2a1pre

I installed Firebug 1.4X.0a12 and ChromeBug 0.5.0a1 in the 20090311 nightly of Minefield 3.2a1pre that had Console2 0.3.10 installed and found that I could only run Minefield once after that.  Any subsequent attempts to run would result in a crash.

I tracked the problem down to a number of calls to jsd.appendFilter().

I managed to reproduce the crash even after disabling Firebug and ChromeBug by calling appendFilter(), but if I disabled Console2 the crash went away.  I tried Console2 0.3.9.1 and 0.3.11a with the same results.  I looked at Console2 and I don't see why it would make a difference if it was installed or not, but it shouldn't cause a browser crash either way. 

Reproducible: Always

Steps to Reproduce:
1. Install Console2 add-on from https://addons.mozilla.org/en-US/firefox/addon/1815 or http://console2.mozdev.org/index.html
2.  Enter the following line into the error console and click evaluate (sometimes you need to click it more than once):

var passDebuggerHalter = { globalObject: null, flags: Components.interfaces.jsdIFilter.FLAG_ENABLED | Components.interfaces.jsdIFilter.FLAG_PASS, urlPattern: "*/debuggerHalter.js", startLine: 0, endLine: 0 }; Components.classes["@mozilla.org/js/jsd/debugger-service;1"].getService(Components.interfaces["jsdIDebuggerService"]).appendFilter(passDebuggerHalter);

Actual Results:  
Crash

Expected Results:  
No crash

http://crash-stats.mozilla.com/report/index/badc6da7-4440-4c80-9c69-a32d42090311

Comment 1

[:Gijs (he/him)]

Uhh, so I suck at debugging crash stacks, but it sure looks to me like something called JSD on "something-other-than-the-main-thread". Which, unless something changed since this dogma was imbued on me, is bound to cause trouble. Timeless, got opinions?

Comment 2

[Michael Kraft [:morac]]

Oh I forgot to mention that the crash does not occur in "Mozilla/5.0 (Windows;
U; Windows NT 5.1; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2".

Comment 3

[:Gijs (he/him)]

(In reply to comment #2)
> Oh I forgot to mention that the crash does not occur in "Mozilla/5.0 (Windows;
> U; Windows NT 5.1; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2".

I don't suppose we could convince you to do a binary search for the crash? :-)

Historic trunk builds can be found at: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/

That'd be very useful!

Comment 4

[Michael Kraft [:morac]]

I should be able to do so, though it might take a while.

I looked at the revision for js/jsd/jsd_xpc.cpp and there haven't been many changes, so I guess I can start there.

http://hg.mozilla.org/mozilla-central/log/ae7ce7e47f5a/js/jsd/jsd_xpc.cpp

Comment 5

[Michael Kraft [:morac]]

Turns out it took less time than I thought it would.  It broke in the 20090108 nightly.

So the following did not crash:

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/01/2009-01-07-03-mozilla-central/

And the following did crash:

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/01/2009-01-08-04-mozilla-central/


That would seem to imply that the fix for bug 136292 caused it.

Comment 6

[Philip Chee]

FWIW

1. Minefield in safe mode crashes as well.
2. I disabled Console2 in the Addons Manager and used the ExecuteJS extension to run the STR in Comment 0 and Minefield crashed again.

Comment 7

[timeless]

0|0|xul.dll|jsds_SyncFilter(FilterRecord *,jsdIFilter *)|hg:hg.mozilla.org/mozilla-central:js/jsd/jsd_xpc.cpp:ae7ce7e47f5a|322|0x4
0|1|xul.dll|jsdService::AppendFilter(jsdIFilter *)|hg:hg.mozilla.org/mozilla-central:js/jsd/jsd_xpc.cpp:ae7ce7e47f5a|2770|0x6
0|2|xul.dll|NS_InvokeByIndex_P|hg:hg.mozilla.org/mozilla-central:xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:ae7ce7e47f5a|101|0x2
0|3|xul.dll|XPCWrappedNative::CallMethod(XPCCallContext &,XPCWrappedNative::CallMode)|hg:hg.mozilla.org/mozilla-central:js/src/xpconnect/src/xpcwrappednative.cpp:ae7ce7e47f5a|2424|0x21

the crash is on thread 0 (main).

i suspect the reason for the partial backtrace is that JIT was on and is about to be Off (enabling the debugger should terminate JIT), however last I checked, JIT didn't provide enough info for stack backtraces to work.

(offtopic) the threadsafe stuff is addressed iirc in:
http://www.webwizardry.net/~timeless/peller.jsdxpc

 NS_IF_RELEASE(rec->filterObject);

is the line that's crashing...

given that the line before it is:
    if (rec->filterObject != filter) {

rec isn't null. which means that filterObject is garbage.

This is odd...
2768     FilterRecord *rec = new FilterRecord;
2770     if (!jsds_SyncFilter (rec, filter)) {

afaict, we're using an uninitialized field.

this is from 36f4da6e262a, it looks like unrelated changes leaked in.

Comment 8

[timeless]

Attachment: revert |new| to PR_NEWZAP

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 367001 [details] [diff] [review]
revert |new| to PR_NEWZAP

rs=me

Comment 10

[timeless]

http://hg.mozilla.org/mozilla-central/rev/d1835d161d78

Comment 11

[Michael Kraft [:morac]]

I can confirm that it's no longer crashing in the 20090312 nightly load.