Closed Bug 926690 Opened 7 years ago Closed 6 years ago
Crash in mozilla::Dispatch
Async Scroll Event Runnable::Run()
This crash just started showing recently in v1.2 monkey testing, twice within 8 hours on: gecko:1b4238480e2bc003069ead83a572fa632cfe03eb gaia:d0f0110f6a907ef386134dc693f5dc5a632a0e9e --- Crash reason: SIGSEGV Crash address: 0x10 Thread 0 (crashed) 0 libxul.so!mozilla::DispatchAsyncScrollEventRunnable::Run() [nsINodeInfo.h : 280 + 0x2] r4 = 0x43a9bd30 r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000001 r8 = 0xbeb1a79f r9 = 0x4031cccc r10 = 0xbeb1a938 fp = 0x00000000 sp = 0xbeb1a6b8 lr = 0x41622235 pc = 0x410e3204 Found by: given as instruction pointer in context 1 libxul.so!nsThread::ProcessNextEvent(bool, bool*) [nsThread.cpp : 622 + 0x5] r4 = 0x4031cca0 r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000001 r8 = 0xbeb1a79f r9 = 0x4031cccc r10 = 0xbeb1a938 fp = 0x00000000 sp = 0xbeb1a758 pc = 0x41622235 Found by: call frame info 2 libxul.so!NS_ProcessNextEvent(nsIThread*, bool) [nsThreadUtils.cpp : 238 + 0xb] r4 = 0x00000000 r5 = 0x403af0c0 r6 = 0x40301e00 r7 = 0x00000001 r8 = 0x00000000 r9 = 0xbeb1a92c r10 = 0xbeb1a938 fp = 0x00000000 sp = 0xbeb1a798 pc = 0x41601795 Found by: call frame info 3 libxul.so!mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) [MessagePump.cpp : 81 + 0x7] r4 = 0x40301df0 r5 = 0x403af0c0 r6 = 0x40301e00 r7 = 0x00000001 r8 = 0x00000000 r9 = 0xbeb1a92c r10 = 0xbeb1a938 fp = 0x00000000 sp = 0xbeb1a7a8 pc = 0x4137f241 Found by: call frame info
Component: General → DOM
Product: Boot2Gecko → Core
Version: unspecified → 26 Branch
Andrew - Looks like this is a DOM regression. Boris has either been the reviewer or has touched this file recently, but he's on PTO. Do you know who's a good backup person to send this bug to that knows about dom/browser-element/BrowserElementParent.cpp?
Do we have a regression range and/or testcase?
(In reply to Olli Pettay [:smaug] from comment #2) > Do we have a regression range and/or testcase? Not at the moment. We do have the ability to generate this crash via monkey test though for CS testing. Is there any specialized logging mvines's team could grab when the crash occurs to provide clarity on the root causes of this bug?
I think the crash is actually rather obvious. patch coming.
Based on the stack this is a 0+offset crash, and it also hints we're accessing nodeinfo. Also, Nothing guarantees that TabParent still has owner element when the runnable runs. So, adding a null check.
Attachment #816858 - Flags: review?(khuey)
Attachment #816858 - Flags: review?(khuey) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/a59a7c31965a Michael, could you ask for approval to those branches where this is needed. (I don't know what koi is and which version of Gecko it will use.)
koi+ will be gecko 26 (currently Aurora) You don't need approval to land.
Thanks kyle https://hg.mozilla.org/releases/mozilla-aurora/rev/c34b0dd3e3a4 Michael, if you still see some similar crashes, please file a new bug. The patch here fixed one obvious case, but since there was no testcase the verify...
:smaug - for sure, thanks!
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
I can't find this crash in Socorro for the last four weeks. Is there anything else I can verify here?
I don't think so. The patch fixed one obvious bug, and if there are more similar bugs they should be fixed in some other bug.
You need to log in before you can comment on or make changes to this bug.