- ES reindexing run last week, with issues - 20% of crashes failed to index, due to a cluster failure that was not noticed until afterwards (they were being sent to a dead node)
- Collector1 problems over the weekend: collector1 (only) fell behind on inserting crashes to HBase. Unsure as to why, investigating bug 944974
- quickly removed it from rotation. It should not impact anything.
- Selena working on porting symbols to Postgres (or something), details
- Interestingly, both 11.9.900.117 and 11.9.900.152 are out on release, and the latter is only catching up very slowly. Are those updates not shipped automatically now?
- bug 943366 - crash in js::ExclusiveContext::getNewType(js::Class const*, js::TaggedProto, JSFunction*)
- Discovered last week. lsblakk has need-info'd dveditz to investigate the security risk.
- Most of the crashes are EXCEPTION_ACCESS_VIOLATION_READ, but there are some more serious EXCEPTION_ACCESS_VIOLATION_WRITE
- Why no bug associated with - nsHtml5StreamParser::ParseAvailableData() - (bug 943150)
- nsStyleContext::DoGetStyleOutline(bool) is a one-build thing only on Aurora, probably another flare-up of the AMD issue.
- I noticed that this morning. It only affects 20131128 Aurora build.
- https://crash-stats.mozilla.com/report/list?signature=mozilla%3A%3Aa11y%3A%3AHyperTextAccessible%3A%3AGetBoundsInFrame%28nsIFrame*%2C%20unsigned%20int%2C%20unsigned%20int%29 is a new regression (since 2013-11-26)
- Filed bug 945308
- bug 943051 has worked well: EMPTY crash reports are down to roughly a quarter when counting per crash day (~1600 crashes/100ADI -> ~400 crashes/100ADI, might be even more when counting per build day). Should be uplifted wherever possible, as it's low risk and should help us a lot to debug the increased amount of OOM crashes.
- bug 942819 - crash in mozilla::layers::DeviceManagerD3D9::Init()
- This is fixed (we're no longer seeing reports against builds after the fix landed). However, Nightly users are sort of stuck here on crashy builds because this is a start-up crash. What is the usual method for getting Nightly users off of start-up crash stuck builds? A few crash report comments say running in safe mode works. Do they do that or have to re-install a latest Nightly? How is that communicated?
- High volume crash on KitKat Nexus 7 2012 - https://crash-stats.mozilla.com/report/list?product=FennecAndroid&range_value=7&range_unit=days&signature=libc.so%400x22048
- Android 4.4 crash on Nexus devices - https://crash-stats.mozilla.com/report/list?signature=libc.so@0x21f90&range_value=7
- Android 4.4 crash on Nexus devices in libstagefright - bug 945340
- still don't have much data for 1.1/1.2
- still need production devices to test 1.1 crash reporting/probably need to do some hack
- need ADI
- need crash api/app
- bug 922215 - Add privileged Web API to intentionally crash in various ways
- bug 908896 Write an about:crashes app
- bug 857843 Gather Gaia error report information for Mozilla apps (e.g. about:gaia-errors similar to about:crashes)
- bug 929029 - [B2G][Settings][Sound] - crash in nsSimpleURI::Release()
- was backed out
- bug 940740 - B2G crash in nsXPCWrappedJS::AddRef()
- bug 871574 - crash in mozilla::dom::indexedDB::PIndexedDBRequestChild::OnMessageReceived
- bug 945335 - crash in audioTrack_callBack_pullFromBuffQueue
- bug 945338 - crash in wpa_ctrl_attach_helper
- Not enough data
same old same old
Needs Verify :
- bug 922334 - crash in sysconf [B2G][Browser][Youtube] Playing youtube videos crash the browser tab
- filed : bug 945837 - crash in sysconf
- bug 929004 - crash in mozilla::system::SetStatusRunnable::Run()