Closed Bug 868741 Opened 8 years ago Closed 8 years ago
crash in Particular
Process Priority Manager::Compute Priority
It has been hit by three users since B2G 18.0/20130501230205 and one since B2G 23.0a1/20130501085824. Stack traces differ between 18.0 and 23.0a1. Here is a crash report in B2G 18.0: bp-891c1d4a-ce32-4906-a5b1-6ef4e2130503. Frame Module Signature Source 0 libxul.so ParticularProcessPriorityManager::ComputePriority nsTArray.h:203 1 libxul.so ParticularProcessPriorityManager::ResetPriority ProcessPriorityManager.cpp:651 2 libxul.so ParticularProcessPriorityManager::Notify ProcessPriorityManager.cpp:506 3 libxul.so mozilla::hal::NotifyWakeLockChange Observer.h:67 4 libxul.so mozilla::hal_impl::ModifyWakeLock HalWakeLock.cpp:239 5 libxul.so mozilla::hal::ModifyWakeLock Hal.cpp:651 6 libxul.so mozilla::dom::power::WakeLock::HandleEvent WakeLock.cpp:257 7 libxul.so nsEventListenerManager::HandleEventSubType nsEventListenerManager.cpp:889 8 libxul.so nsEventListenerManager::HandleEventInternal nsEventListenerManager.cpp:962 9 libxul.so nsEventTargetChainItem::HandleEvent nsEventListenerManager.h:144 10 libxul.so nsEventTargetChainItem::HandleEventTargetChain nsEventDispatcher.cpp:316 11 libxul.so nsEventTargetChainItem::HandleEventTargetChain nsEventDispatcher.cpp:371 12 libxul.so nsEventDispatcher::Dispatch nsEventDispatcher.cpp:634 13 libxul.so nsEventDispatcher::DispatchDOMEvent nsEventDispatcher.cpp:694 14 libxul.so nsINode::DispatchEvent nsINode.cpp:1078 15 libxul.so nsContentUtils::DispatchEvent nsContentUtils.cpp:3547 16 libxul.so nsContentUtils::DispatchTrustedEvent nsContentUtils.cpp:3518 17 libxul.so nsDocument::UpdateVisibilityState nsDocument.cpp:9943 18 libxul.so nsRunnableMethodImpl<nsrefcnt , false>::Run nsThreadUtils.h:366 19 libxul.so nsThread::ProcessNextEvent nsThread.cpp:620 20 libxul.so NS_ProcessNextEvent_P nsThreadUtils.cpp:237 21 libxul.so mozilla::ipc::MessagePump::Run MessagePump.cpp:82 22 libxul.so MessageLoop::RunInternal message_loop.cc:219 23 libxul.so MessageLoop::Run message_loop.cc:212 24 libxul.so nsBaseAppShell::Run nsBaseAppShell.cpp:163 25 libxul.so nsAppStartup::Run nsAppStartup.cpp:290 26 libxul.so XREMain::XRE_mainRun nsAppRunner.cpp:3794 27 libxul.so XREMain::XRE_main nsAppRunner.cpp:3860 28 libxul.so XRE_main nsAppRunner.cpp:3935 29 b2g main nsBrowserApp.cpp:168 30 libc.so __libc_init libc_init_dynamic.c:114 31 libc.so __cxa_atexit atexit.c:99 32 @0xbec01d3c More reports at: https://crash-stats.mozilla.com/report/list?signature=ParticularProcessPriorityManager%3A%3AComputePriority
(leo+, this is showing up as a part of stability test)
blocking-b2g: --- → leo+
Reproducible end-user STR is in the dupe of this bug.
Component: General → IPC
Product: Boot2Gecko → Core
Version: unspecified → Trunk
Crashing in this file: https://hg.mozilla.org/mozilla-central/file/b842d26dd5f0/dom/ipc/ProcessPriorityManager.cpp
Assignee: nobody → justin.lebar+bug
This is crashing on nsTArray::Length, so https://hg.mozilla.org/mozilla-central/file/b842d26dd5f0/dom/ipc/ProcessPriorityManager.cpp#l739 This probably means that mContentParent is a dangling pointer.
Marked as security-sensitive because I'm afraid this is a use-after-free. We can unprotect it if I'm wrong.
Hmm...is this a regression from bug 844323 by any chance? If so, this should be nominated to tef?
It's definitely a regression from that bug. But I don't see why that should affect whether or not it blocks tef.
(In reply to Justin Lebar [:jlebar] from comment #8) > It's definitely a regression from that bug. But I don't see why that should > affect whether or not it blocks tef. My original reasoning is that this is 1.01 affected and a crash regression from a tef+ blocker that's reproducible and security-sensitive. Unless there's some argument that states that we should block on this for 1.1, but not 1.01 that I'm not seeing here. Do you have any concerns on blocking on this for 1.01?
blocking-b2g: leo+ → tef?
> Do you have any concerns on blocking on this for 1.01? Definitely not. My only point is that a crash that affects 1.0.1 and is reproducible and s-s is bad, regardless of how it was introduced.
Oh goodness, this is just a null-pointer exception. I should have looked more closely at the crash report: > Crash Address 0x168 In other words, null plus change.
Un-marking as security-sensitive, per jlebar's request in comment 11 & in IRC (and since he's the one who initially requested that it be hidden, back in Comment 6).
Comment on attachment 746595 [details] [diff] [review] Patch, v1 Review of attachment 746595 [details] [diff] [review]: ----------------------------------------------------------------- LGTM!
Attachment #746595 - Flags: review?(bent.mozilla) → review+
This is a safe crash-fix patch that we should take on tef.
Naoki, the use of the topcrash keyword for B2G should be documented in https://wiki.mozilla.org/CrashKill/Topcrash.
I hit this crash twice today already on leo. Please uplift.
(In reply to Scoobidiver from comment #18) > Naoki, the use of the topcrash keyword for B2G should be documented in > https://wiki.mozilla.org/CrashKill/Topcrash. Done.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla23
Ryan, can you please uplift to v1-train while the v1.0.1 folks consider the tef? request. leo+ was set @ comment 1
Literally right after I push a bunch of other stuff to b2g18, of course... https://hg.mozilla.org/releases/mozilla-b2g18/rev/f1fdd7d57305
This was tef?'ed six days ago, well before the most recent deadline. How often is tef triage happening these days? Surely when a deadline is coming up, we should clear our blocker backlog so that important patches don't miss the boat. If the delay here means that this misses 1.0.1, I'll be pretty disappointed. But even if not, the delay means that taking this patch is more risky, since it'll get less testing (although I still think we're better off taking this patch than not). Triage is supposed to decrease our risk; something is very wrong when development becomes more risky due to our triage practices.
(In reply to Justin Lebar [:jlebar] from comment #25) > This was tef?'ed six days ago, well before the most recent deadline. > > How often is tef triage happening these days? Surely when a deadline is > coming up, we should clear our blocker backlog so that important patches > don't miss the boat. > > If the delay here means that this misses 1.0.1, I'll be pretty disappointed. > But even if not, the delay means that taking this patch is more risky, since > it'll get less testing (although I still think we're better off taking this > patch than not). Triage is supposed to decrease our risk; something is very > wrong when development becomes more risky due to our triage practices. Sorry Justin, somehow I missed this bug, I've marked as tef+
blocking-b2g: tef? → tef+
You need to log in before you can comment on or make changes to this bug.