CrashKill/2013-12-02

From MozillaWiki
Jump to: navigation, search

General

Socorro

  • 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)
    • Restarted node, filed a bug to get better monitoring on ES bug 945248
    • Reprocessing of the missed crashes will proceed shortly bug 945293
  • 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

Flash

  • 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?

Desktop

Beta

  • 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)

Aurora

  • 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.

Trunk

  • 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)
  • 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?

Mobile

B2G

General

  • 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)

1.3

  • 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
    • reopened
  • bug 945335 - crash in audioTrack_callBack_pullFromBuffQueue

1.2/1.1

  • bug 945338 - crash in wpa_ctrl_attach_helper
  • Not enough data

1.0.1

same old same old

Misc

Needs Verify :

  • bug 922334 - crash in sysconf [B2G][Browser][Youtube] Playing youtube videos crash the browser tab
  • bug 929004 - crash in mozilla::system::SetStatusRunnable::Run()
    • verified.

Notes

Upcoming PTO

Retrieved from "https://wiki.mozilla.org/index.php?title=CrashKill/2013-12-02&oldid=779729"