Closed Bug 494617 Opened 11 years ago Closed 11 years ago
Crash [@ memmove | ns
TArray _base::Shift Data | ns XULDocument::Resolve Forward References] with overlay, observes, event handlers removing window and xmlhttprequest
1.12 KB, application/java-archive
47.18 KB, text/html
1.88 KB, patch
|Details | Diff | Splinter Review|
See zipped up testcase, which crashes current trunk build and Firefox3.0.x after 1 second. To reproduce, extract the zipped up testcase, then open up the file named 'parentframe.htm'. http://crash-stats.mozilla.com/report/index/d45a612e-9960-4f8a-9244-833ef2090523?p=1 0 mozcrt19.dll memmove MEMCPY.ASM:188 1 xul.dll nsTArray_base::ShiftData obj-firefox/xpcom/build/nsTArray.cpp:173 2 xul.dll nsXULDocument::ResolveForwardReferences content/xul/document/src/nsXULDocument.cpp:1210 3 xul.dll nsXULDocument::ResumeWalk content/xul/document/src/nsXULDocument.cpp:3136 4 xul.dll nsXULDocument::OnPrototypeLoadDone content/xul/document/src/nsXULDocument.cpp:625 5 xul.dll nsXULDocument::EndLoad content/xul/document/src/nsXULDocument.cpp:608 6 xul.dll XULContentSinkImpl::DidBuildModel content/xul/document/src/nsXULContentSink.cpp:278 7 xul.dll nsExpatDriver::DidBuildModel parser/htmlparser/src/nsExpatDriver.cpp:1319 8 xul.dll nsParser::DidBuildModel parser/htmlparser/src/nsParser.cpp:1563 9 xul.dll nsParser::ResumeParse parser/htmlparser/src/nsParser.cpp:2312 10 nspr4.dll _MD_CURRENT_THREAD nsprpub/pr/src/md/windows/w95thred.c:308 11 xul.dll nsBaseChannel::OnStopRequest netwerk/base/src/nsBaseChannel.cpp:680 12 xul.dll nsInputStreamPump::OnStateStop netwerk/base/src/nsInputStreamPump.cpp:576 13 xul.dll nsInputStreamPump::OnInputStreamReady netwerk/base/src/nsInputStreamPump.cpp:401 14 xul.dll nsOutputStreamReadyEvent::Run xpcom/io/nsStreamUtils.cpp:190 15 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:510 16 xul.dll NS_ProcessNextEvent_P obj-firefox/xpcom/build/nsThreadUtils.cpp:230 17 xul.dll xul.dll@0x3dac0f 18 xul.dll NS_InvokeByIndex_P xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:101 19 xul.dll XPCWrappedNative::CallMethod js/src/xpconnect/src/xpcwrappednative.cpp:2491 Firefox3 breakpad report: http://crash-stats.mozilla.com/report/index/b972a51b-44bf-401c-8131-026ae2090523?p=1 0 @0x325dc0
I don't seem to be able to crash in a mac build. In a windows debug build, I see these assertions prior to the crash: ###!!! ASSERTION: Already have a document. Unbind first!: '!GetCurrentDoc()', f ile c:/mozilla-build-1.3/src/content/base/src/nsGenericElement.cpp, line 2520 ###!!! ASSERTION: Already have an undisplayed context entry for aContent: '!GetU ndisplayedContent(aContent)', file c:/mozilla-build-1.3/src/layout/base/nsFrameM anager.cpp, line 593
Is there any particular reason why this should block 1.9.1?
Attachment #379372 - Attachment mime type: application/zip → application/java-archive
In Firefox 3.0.x I got a similar stack (single-frame, 0x31fe50) but windbg had slightly more information (fonts? Something Cycle-collected?). It was a DEP violation which are usually pretty trivially exploited with heapsprays. After changing the MIME type to application/java-archive I was able to get the testcase to work without saving it: jar:https://bugzilla.mozilla.org/attachment.cgi?id=379372!/parentframe.htm Had to refresh a few times before it crashed. 0:000> !exploitable -v Event Type: Exception Exception Faulting Address: 0x31fe50 First Chance Exception Type: STATUS_ACCESS_VIOLATION (0xC0000005) Exception Sub-Type: Data Execution Protection (DEP) Violation Exception Hash (Major/Minor): 0x2b336c41.0x66143413 Stack Trace: Unknown xul!gfxTextRun::HasDetailedGlyphs+0xac26 xul!NS_CycleCollectorForget_P+0xb60 xul!gfxTextRun::Create+0x4d2e xul!gfxWindowsPlatform::ResolveFontName+0x61e7 xul!gfxTextRun::Create+0x4e06 xul!gfxTextRun::gfxTextRun+0x2fd1 xul!gfxWindowsFontGroup::GetFontAt+0x6c0 Instruction Address: 0x31fe50 Description: Data Execution Prevention Violation Short Description: DEPViolation Exploitability Classification: EXPLOITABLE Recommended Bug Title: Exploitable - Data Execution Prevention Violation starting at Unknown Symbol @ 0x92e1dcffff000a (Hash=0x2b336c41.0x66143413) User mode DEP access violations are exploitable.
I thought this might be related to bug 485799, and according to bug 485799, comment 2, it was a topcrash (at least back then).
I also crash with this testcase (open the file named 'parentframe2.htm'). It seems like the same kind of crash to me, because it also uses xmlhttprequest and the first part of the stack is the same. Although, it doesn't seem to crash in Firefox 3.0.x. http://crash-stats.mozilla.com/report/index/d36f7528-9c0d-4158-8459-08b6c2090604?p=1 0 mozcrt19.dll memmove MEMCPY.ASM:188 1 xul.dll nsTArray_base::ShiftData obj-firefox/xpcom/build/nsTArray.cpp:173 2 xul.dll nsTArray<nsAutoPtr<PresShell::nsDelayedEvent> >::RemoveElementsAt obj-firefox/dist/include/nsTArray.h:664 3 xul.dll nsTArray<nsAutoPtr<PresShell::nsDelayedEvent> >::RemoveElementAt obj-firefox/dist/include/nsTArray.h:669 4 xul.dll xul.dll@0x332e9f 5 xul.dll FireOrClearDelayedEvents content/base/src/nsDocument.cpp:7508 6 xul.dll nsDelayedEventDispatcher::Run content/base/src/nsDocument.cpp:7525 7 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:510 8 xul.dll nsBaseAppShell::Run widget/src/xpwidgets/nsBaseAppShell.cpp:170 9 xul.dll nsAppStartup::Run toolkit/components/startup/src/nsAppStartup.cpp:193 10 nspr4.dll PR_GetEnv 11 firefox.exe wmain toolkit/xre/nsWindowsWMain.cpp:110 12 firefox.exe firefox.exe@0x21a7 13 kernel32.dll kernel32.dll@0x17076
There's a nested call to nsXULDocument::ResolveForwardReferences() for the same document.
Assignee: nobody → matspal
This fixes the first testcase. I can't reproduce the second (had to fix the file suffix to .htm -- maybe wrong file? ... got sendKeyEvent exception even with right priviligies...)
(In reply to comment #7) > I can't reproduce the second > (had to fix the file suffix to .htm -- maybe wrong file? ... Sorry, my description of how to reproduce was insufficient. While you have the 'parentframe.htm' file opened, you have to keep the tab key pressed.
Comment on attachment 381527 [details] testcase2, zipped, using enhanced privileges It turns out this is bug 498530 (and I screwed up with this testcase anyway, adding the wrong file). I attached the correct testcase in bug 498530.
Attachment #381527 - Attachment is obsolete: true
(In reply to comment #2) > Is there any particular reason why this should block 1.9.1? Topcrash for the past week at #2 for "Results within 1 weeks of now, and the product is one of Firefox, and the version is one of Firefox:3.5." - now numbers >4,400 crashes. I checked a few stacks at: http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.5&query_search=signature&query_type=exact&query=&date=&range_value=1&range_unit=weeks&do_query=1&signature=memmove and their first and second lines seem to be at memmove and nsTArray_base::ShiftData - nominating blocking22.214.171.124? just-in-case. It's been a month ever since any activity on this bug.
Mats: Any update on this bug? Given our focus on stability for Firefox 3.5.1, it's now blocking that release.
Flags: blocking126.96.36.199? → blocking188.8.131.52+
blocking1.9.1: --- → .2+
Flags: blocking184.108.40.206+ → blocking220.127.116.11-
Mats: are you still working on this issue? jst: can you either follow up with mats or reassign? this is a topcrash which we need to fix for the 3.5.2 release at the end of the month
I don't think this is a topcrash, the topcrash seems to be something with a "too low memory" alert or something.
(In reply to comment #13) > I don't think this is a topcrash, the topcrash seems to be something with a > "too low memory" alert or something. Those stacks looks indeed different: http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.5.1&query_search=signature&query_type=exact&query=&date=&range_value=1&range_unit=weeks&do_query=1&signature=memmove Martijn, shall I file a new bug? I can't find a related one yet.
Sure, you can do that. But a testcase for it, would be nice.
I have taken a look at several of those top crashers and all have the same signature in the first two frames: 0 mozcrt19.dll memmove MEMCPY.ASM:188 1 xul.dll nsTArray_base::ShiftData obj-firefox/xpcom/build/nsTArray.cpp:173 I'll not create a new bug for now. Anyone who can tell for sure how reliable the 2nd frame is to determine if both are the same issue or not? timeless?
Summary: Crash [@ memmove] with overlay, observes, event handlers removing window and xmlhttprequest → Crash [@ memmove | nsTArray_base::ShiftData] with overlay, observes, event handlers removing window and xmlhttprequest
If it's only those two frames that match, you should definitely file a separate bug. If it's also from nsXULDocument::ResolveForwardReferences there's a chance it could be the same as this, but it's probably still worth a separate bug.
Flags: blocking1.9.2? → wanted1.9.2+
I have filed bug 507114 on the topcrasher.
Summary: Crash [@ memmove | nsTArray_base::ShiftData] with overlay, observes, event handlers removing window and xmlhttprequest → Crash [@ memmove | nsTArray_base::ShiftData | nsXULDocument::ResolveForwardReferences] with overlay, observes, event handlers removing window and xmlhttprequest
This will have to wait. Mats/jst: Who's working on this?
blocking1.9.1: .2+ → needed
Mats, feel free to jump in here if you have cycles to spend on this, but we need to get this moving. Smaug, do you think you could spend some time looking at this topcrasher?
Assignee: matspal → Olli.Pettay
I can look at this during this weekend.
I can't reproduce this on trunk using the first testcase.
Can't reproduce on 1.9.1 (OSX) either. Will try linux.
Ok, crashes on linux.
Comment on attachment 381988 [details] [diff] [review] wip I think we should take Mats' patch.
Comment on attachment 381988 [details] [diff] [review] wip Seems fine to me.
Attachment #381988 - Flags: superreview?(jst) → superreview+
Comment on attachment 381988 [details] [diff] [review] wip This patch still makes sense to me, but I have to admit I don't know this part of the code very well. FWIW, it fixes the crash and pass unit tests on TryServer. I'll push it to m-c tomorrow.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
Attachment #381988 - Flags: approval1.9.2? → approval1.9.2+
Comment on attachment 381988 [details] [diff] [review] wip This doesn't appear to fix the topcrash so we don't need to cram this in after the code freeze. We'll catch it in the next round (tree opens in early Oct)
Comment on attachment 381988 [details] [diff] [review] wip Approved for 18.104.22.168 and 22.214.171.124, a=dveditz for release-drivers
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/8f3cbd759f80 On CVS trunk: mozilla/content/xul/document/src/nsXULDocument.cpp 1.838
Verified fixed on trunk and 1.9.2 with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091108 Minefield/3.7a1pre (.NET CLR 3.5.30729) ID:20091108045014 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b2pre) Gecko/20091106 Namoroka/3.6b2pre (.NET CLR 3.5.30729) ID:20091106050124
Status: RESOLVED → VERIFIED
Verified for 1.9.1 with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199pre) Gecko/20091119 Shiretoko/3.5.6pre (.NET CLR 3.5.30729) Verified for 1.9.0. with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52pre) Gecko/2009111921 GranParadiso/3.0.16pre (.NET CLR 3.5.30729) using attached testcase after verifying crash with testcase in 184.108.40.206 and 220.127.116.11.
Attachment #381527 - Attachment mime type: application/zip → application/java-archive
Crash Signature: [@ memmove | nsTArray_base::ShiftData | nsXULDocument::ResolveForwardReferences]
You need to log in before you can comment on or make changes to this bug.