Crash after searching at [@ nsSVGInnerSVGFrame::GetOverrideCTM()] [@ JS_HashTableRawLookup]




12 years ago
8 years ago


(Reporter: stevee, Assigned: peterv)


({crash, regression})

Dependency tree / graph
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)


(crash signature, )


(2 attachments)

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
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 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 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 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
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: Gecko/20071214 BonEcho/
Keywords: qawanted, regression
Flags: blocking-firefox3?
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.
The stack looks a bit xbl-ish to me.
Steve, I guess it's not possible to get a regression range, right?
> 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.  :(
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.
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.
On Linux, glibc (free) says: "corrupted double-linked list" and then aborts.
OS: Windows 2000 → All
Mats, do you have valgrind available?
Posted file 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...
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.
OS: All → Windows 2000
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.
OS: Windows 2000 → All
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?
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.
Blocks: 406106
Keywords: qawanted
Duplicate of this bug: 409343
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.
Blocks: 409063
Blocks: 409382
Component: General → XPConnect
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: general → xpconnect
Flags: blocking1.9?
+'ing with P3 priority.  Please adjust priority as needed.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
Peter: looks like a cycle collector issue of some sort? Could this be another manifestation of running unlink while in gc?
Assignee: nobody → peterv
I think this should be P2, since it's a memory-corruption crash.
Priority: P3 → P2
From comment 9 to comment 11, looks like this might be a dupe of bug 406800?
Ah, indeed.  I missed Unlink() nulling out mJSVal.
Depends on: 406800
Closed: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 406800
Crash Signature: [@ nsSVGInnerSVGFrame::GetOverrideCTM()] [@ JS_HashTableRawLookup]
You need to log in before you can comment on or make changes to this bug.