502384 - Crash running chrome mochitests on debug build (xpcom_core.dll!nsQueryInterface::operator())

Status: RESOLVED WORKSFORME

(Core :: XBL, defect)

Description

[Alex Vincent [:WeirdAl]]

Attachment: stack trace

Steps to reproduce:
(1) Create a debug build of Firefox 3.5 code.
(2) cd ../fx-debug
(3) python _tests/testing/mochitest/runtests.py --chrome
(4) Attach debugger
(5) Click "Run Chrome Tests" button and wait for tests to complete.

Expected results:  Tests complete normally.
Actual results: Crash.

At frame 0,
>	xpcom_core.dll!nsQueryInterface::operator()(const nsID & aIID={...}, void * * answer=0x0014c644)  Line 47 + 0x15 bytes	C++

+		mRawPtr	0x6f31e640 _js_ObjectOps	nsISupports *

It looks like the autocomplete.xml#autocomplete-tree binding failed to find its base binding (which at that point looed like the aforementioned _js_ObjectOps).

Reproducible: Every time.  I tried this on two different Windows machines.

Comment 1

[Alex Vincent [:WeirdAl]]

Test blows up either during or after executing chrome://mochikit/content/chrome/widget/test/test_keycodes.xul.  It could be after because this is the last test in the harness, and running just that test alone does not cause a crash.

Comment 2

[Alex Vincent [:WeirdAl]]

*sigh* https://bugzilla.mozilla.org/show_bug.cgi?id=442774#c68 talks about a very similar crash, and no bug was filed to investigate that.

Comment 3

[Boris Zbarsky [:bzbarsky]]

This worksforme in a current m-c mac build.  Is this 3.5-branch only?  What makes you think it's XBL-related?

Comment 4

[Alex Vincent [:WeirdAl]]

bz: I tested with 1.9.1 code, Vista 64-bit.  I guessed XBL based on the stack - I had a debugger attached to catch the fault, and I'm not used to seeing nsCOMPtr's QueryInterface failing like that.  XBL seemed the most obvious to me.

Comment 5

[Boris Zbarsky [:bzbarsky]]

This worksforme in a 1.9.1 build too (still Mac).

If you can reproduce reliably, care to actually post more of your stack?  Your frame 0 just looks like QI on a garbage pointer...  No idea why you decided XBL unless it was higher up on the stack.

Comment 6

[Alex Vincent [:WeirdAl]]

:( I just tried this on a Windows XP laptop, and the crash didn't happen there.  It did happen on a Windows XP desktop, though (that I was doing other browsing and work on the desktop at the time).

<bz>	cc peterv? Maybe we're somehow cycle-collecting stuff here too early?
<bz>	but I mean....
<bz>	your mBindingURI actually points to _garbage_
<bz>	not just null
<bz>	it could also be that there's just memory corruption somewhere else here
* bz	would love a run of this stuff under valgrind....
<bz>	I really don't know what to tell you
<bz>	I really doubt this is an XBL bug
<bz>	I suspect something is scribbling on memory
<bz>	but I have no idea what

Comment 7

[Daniel Veditz [:dveditz]]

"run all the tests" isn't a testcase... do you know which test it actually is? can you reduce the problem to something manageable?

Earlier you said vista 64-bit. Is your WinXP also 64-bit? Is that an important part of the problem? Or is the platform set to x86 rather than x86_64 accurate?

Hiding bug based on garbage in stack, but something that someone else can repro would be nice. Setting to unconfirmed

Comment 8

[Alex Vincent [:WeirdAl]]

(In reply to comment #7)
> "run all the tests" isn't a testcase... do you know which test it actually is?
> can you reduce the problem to something manageable?

I can try - I suspect test_keycodes.xul, based on comment 1 and comment 2.

> Earlier you said vista 64-bit. Is your WinXP also 64-bit? Is that an important
> part of the problem? Or is the platform set to x86 rather than x86_64 accurate?

Actually, I was able to reproduce this on 32-bit Windows XP and 64-bit Windows Vista.

Comment 9

[Al Billings [:abillings - ex-MoCo]]

There has been no activity in two years and questions about how to reproduce haven't really been answered since then. 

Alex, please reopen if it still occurs and you can reproduce in current builds.

Resolving works for me right now.

Comment 10

[Alex Vincent [:WeirdAl]]

Nah, close this.  FF3.5 is dead and gone, and I clearly haven't thought of this bug since mid-2009.