409208 - Crash after searching at www.edlproject.eu [@ nsSVGInnerSVGFrame::GetOverrideCTM()] [@ JS_HashTableRawLookup]

Status: RESOLVED DUPLICATE of bug 406800

(Core :: XPConnect, defect, P2)

Description

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b3pre) Gecko/2007122005 Minefield/3.0b3pre ID:2007122005

1. New profile, start firefox
2. Visit http://www.edlproject.eu/
3. In the search box at the bottom, enter "banana" and click search.
4. Results page loads, wait for crash.
5. If no crash, close tab, then reopen closed tab.

bp-f727eeee-aef8-11dc-ba70-001a4bd43e5c [@ NTDLL.DLL@0x4aff8]
bp-3d50d914-af10-11dc-b04a-001a4bd43e5c [@ JS_HashTableRawLookup]
bp-d3e9207a-af10-11dc-98d5-001a4bd43ef6 [@ NTDLL.DLL@0x4ae88]
bp-5c5f5ef5-af11-11dc-acd5-001a4bd43e5c [@ NTDLL.DLL@0x4d98b]
bp-983c6ad7-af11-11dc-88fb-001a4bd43ed6 [@ NTDLL.DLL@0x4aea2]
bp-ff39b55e-af11-11dc-9b04-001a4bd43ef6 [@ nsSVGInnerSVGFrame::GetOverrideCTM()]
bp-4002ff97-af12-11dc-9045-001a4bd43ef6 [@ JS_HashTableRawLookup]

Signature	JS_HashTableRawLookup
UUID	3d50d914-af10-11dc-b04a-001a4bd43e5c
Time	2007-12-20 07:28:00-08:00
Build ID	2007122005
OS	Windows NT
OS Version	5.0.2195 Service Pack 4
CPU	x86
CPU Info	AuthenticAMD family 6 model 8 stepping 1
Crash Reason	EXCEPTION_ACCESS_VIOLATION
Crash Address	0xffffffff947f0206
Frame  	Signature  	Source
0 	JS_HashTableRawLookup 	
1 	js_EnterSharpObject 	
2 	js_TraceSharpMap 	
3 	NTDLL.DLL@0x32c0b 	


Signature	nsSVGInnerSVGFrame::GetOverrideCTM()
UUID	ff39b55e-af11-11dc-9b04-001a4bd43ef6
Time	2007-12-20 07:40:33-08:00
Build ID	2007122005
OS	Windows NT
OS Version	5.0.2195 Service Pack 4
CPU	x86
CPU Info	AuthenticAMD family 6 model 8 stepping 1
Crash Reason	EXCEPTION_ACCESS_VIOLATION
Crash Address	0xc0118
Frame  	Signature  	Source
0 	nsSVGInnerSVGFrame::GetOverrideCTM() 	mozilla/content/xbl/src/nsXBLInsertionPoint.cpp:91
1 	ChangeDocumentForDefaultContent 	mozilla/content/xbl/src/nsXBLBinding.cpp:569
2 	nsBaseHashtable<nsURIHashKey, nsCOMPtr<nsICSSStyleSheet>, nsICSSStyleSheet*>::s_EnumStub(PLDHashTable*, PLDHashEntryHdr*, unsigned int, void*) 	nsBaseHashtable.h:346
3 	PL_DHashTableEnumerate 	pldhash.c:724
4 	nsBaseHashtable<nsVoidPtrHashKey, nsCOMPtr<nsIAccessNode>, nsIAccessNode*>::Enumerate(PLDHashOperator (*)(void const*, nsCOMPtr<nsIAccessNode>&, void*), void*) 	nsBaseHashtable.h:221
5 	nsXBLBinding::ChangeDocument(nsIDocument*, nsIDocument*) 	mozilla/content/xbl/src/nsXBLBinding.cpp:1152
6 	nsBindingManager::ChangeDocumentFor(nsIContent*, nsIDocument*, nsIDocument*) 	mozilla/content/xbl/src/nsBindingManager.cpp:618
7 	nsGenericElement::UnbindFromTree(int, int) 	mozilla/content/base/src/nsGenericElement.cpp:2130
8 	nsXULElement::UnbindFromTree(int, int) 	mozilla/content/xul/content/src/nsXULElement.cpp:832
9 	nsGenericElement::doRemoveChildAt(unsigned int, int, nsIContent*, nsIContent*, nsIDocument*, nsAttrAndChildArray&) 	mozilla/content/base/src/nsGenericElement.cpp:2796
10 	nsGenericElement::RemoveChildAt(unsigned int, int) 	mozilla/content/base/src/nsGenericElement.cpp:2726
11 	nsXULElement::RemoveChildAt(unsigned int, int) 	mozilla/content/xul/content/src/nsXULElement.cpp:952
12 	nsGenericElement::doRemoveChild(nsIDOMNode*, nsIContent*, nsIDocument*, nsIDOMNode**) 	mozilla/content/base/src/nsGenericElement.cpp:3372
13 	nsGenericElement::RemoveChild(nsIDOMNode*, nsIDOMNode**) 	mozilla/content/base/src/nsGenericElement.cpp:2942
14 	NS_InvokeByIndex_P 	mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:101
15 	AutoJSSuspendRequest::SuspendRequest() 	mozilla/js/src/xpconnect/src/xpcprivate.h:3406
16 	AffixMgr::compound_check(char const*, int, short, short, short, short, hentry**, char, int*, int*, char) 	mozilla/extensions/spellcheck/hunspell/src/affixmgr.cpp:1707


Signature	JS_HashTableRawLookup
UUID	4002ff97-af12-11dc-9045-001a4bd43ef6
Time	2007-12-20 07:42:25-08:00
Build ID	2007122005
OS	Windows NT
OS Version	5.0.2195 Service Pack 4
CPU	x86
CPU Info	AuthenticAMD family 6 model 8 stepping 1
Crash Reason	EXCEPTION_ACCESS_VIOLATION
Crash Address	0x8
Frame  	Signature  	Source
0 	JS_HashTableRawLookup 	
1 	js_InitNumberClass 	
2 	js_InitNumberClass 	
3 	js_InitNumberClass 	
4 	js_EnterSharpObject 	
5 	js_TraceSharpMap 	
6 	js_GetSlotThreadSafe

Comment 1

[Steve England [:stevee]]

This is a regression too, since I can't get it to crash on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.12pre) Gecko/20071214 BonEcho/2.0.0.12pre

Comment 2

[Steve England [:stevee]]

I should probably clarify:

   4. Results page loads, wait for crash.

After the page has loaded (throbber has stopped) results are still being returned... you can see on the left hand side column all the libraries that are getting searched with a number next to them when they have been searched... You have to wait for this to finish before you can expect a crash. So step 4 should probably be:

  4. Results page loads and starts to return results... wait until all libraries listed on the left hand column have returned their results, and the "Stop The Search" button has disappeared.

Comment 3

[Martijn Wargers (dead)]

The stack looks a bit xbl-ish to me.
Steve, I guess it's not possible to get a regression range, right?

Comment 4

[Boris Zbarsky [:bzbarsky]]

> The stack looks a bit xbl-ish to me.

Sadly, it's also completely broken (e.g. frame 15 doen't actually call frame 14).

It looks like there is some fun memory corruption going on here, including corrupting the stack.  :(

Comment 5

[Steve England [:stevee]]

Here's some more stacks from other people; perhaps they will be of more use.

bp-a8351863-aee1-11dc-ac38-001a4bd43ed6 [@ RtlpCoalesceFreeBlocks]
bp-e29d2014-aee1-11dc-a477-001a4bd46e84 [@ RtlpCoalesceFreeBlocks]
bp-679320fd-aee2-11dc-ac2f-001a4bd43e5c [@ RtlAllocateHeap]

bp-53ffcdbd-af15-11dc-ad4a-001a4bd46e84 [@ RtlpCoalesceFreeBlocks]
bp-ab49bfcf-af29-11dc-ae03-001a4bd43ed6 [@ RtlAllocateHeap]

I won't copy the whole stacks here in case they're all useless - I'll leave that to someone else in case they spot a useful stack.

Comment 6

[Steve England [:stevee]]

OK I've been looking for a range to narrow the problem down. Unfortunately there is a period on the trunk where the website doesn't work properly, so I can't tell when the crash was introduced.

Trunk builds up to 2007012602 return search results, and no crash occurs.

Builds between 2007012715 and 2007120521 do not return search results, and so no crash occurs.

Builds after 2007120601 are returning search results again, but this time they crash.

So there's a period between 20070127 and 20071205 where I can't test when the crash was introduced because the website isn't working as expected.

Comment 7

[Mats Palmgren (inactive)]

Attachment: stack, Linux debug build

On Linux, glibc (free) says: "corrupted double-linked list" and then aborts.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Mats, do you have valgrind available?

Comment 9

[Mats Palmgren (inactive)]

Attachment: valgrind output

Yeah, I have a dedicated tree for valgrind debugging.
This is what turned up on the first run... let me know what data
you want...

Comment 10

[Boris Zbarsky [:bzbarsky]]

Hmm.  At a guess, we're double-destroying the variant or some such... Or for some reason we're initializing it with one of the JS engine's strings.  More likely the latter.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Can we flag cases in xpcvariant when mJSVal is not JSVAL_IS_STRING but the type is a string type?  That's another way we could perhaps hit this, maybe.

Comment 12

[Arie Paap [:wildmyron]]

I just filed bug 409343 , after which I found this one. It seems similar to me but then I really have no idea. It seems to have a more consistent stack (for me at least) when it crashes [@ RtlFreeHeap] [@ nsVariant::Cleanup]. What's needed to know if it's the same bug?

Comment 13

[Mats Palmgren (inactive)]

Thanks for the lead Arie, following that trail leads to bug 406106.
Backing out bug 406106 locally fixes the crash in this bug for me.

Comment 15

[Boris Zbarsky [:bzbarsky]]

This should almost certainly be in Core:XPConnect.

That said, I can't tell why it's failing...  The traverse/unlink for xpcvariant look OK to me.

Comment 16

[Damon Sicore (:damons)]

+'ing with P3 priority.  Please adjust priority as needed.

Comment 17

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Peter: looks like a cycle collector issue of some sort? Could this be another manifestation of running unlink while in gc?

Comment 18

[Boris Zbarsky [:bzbarsky]]

I think this should be P2, since it's a memory-corruption crash.

Comment 19

[Peter Van der Beken [:peterv]]

From comment 9 to comment 11, looks like this might be a dupe of bug 406800?

Comment 20

[Boris Zbarsky [:bzbarsky]]

Ah, indeed.  I missed Unlink() nulling out mJSVal.