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
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:22.214.171.124pre) Gecko/20071214 BonEcho/126.96.36.199pre
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.
Mats, do you have valgrind available?
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.
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.
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.
Component: General → XPConnect
Product: Firefox → Core
QA Contact: general → xpconnect
+'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
Ah, indeed. I missed Unlink() nulling out mJSVal.
Depends on: 406800
Status: NEW → RESOLVED
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.