CrashKill/2014-06-09: Difference between revisions
Jump to navigation
Jump to search
Line 10: | Line 10: | ||
==Socorro== | ==Socorro== | ||
* symbols upload working! some caveats: | |||
** not linked | |||
** .tar.gz not unpacking correctly, .zip working fine | |||
** private symbols are not filtered out, yet | |||
* logged in users can see their own crashes! | |||
** https://crash-stats.mozilla.com/your-crashes/ | |||
==Flash== | ==Flash== |
Revision as of 17:05, 9 June 2014
General
- Numbers on http://arewestableyet.com/ and KaiRo's long-term graphs are very late almost every day because of bug 1010257 (scheduling issue in Socorro).
Previous Action Items
- [Carryover] KaiRo/liz to evaluate options for public stability list. KaiRo sent an email to Liz, didn't a get a reply yet.
- bug 883134:
- juanb to be on point to get reproducible case with community
- bsmedberg to talk to johns to look into it
- KaiRo to ask relman to contact GAS Tecnologia
- bsmedberg to find nightly regression range for bug 768395
Socorro
- symbols upload working! some caveats:
- not linked
- .tar.gz not unpacking correctly, .zip working fine
- private symbols are not filtered out, yet
- logged in users can see their own crashes!
Flash
Desktop
bug 1022471 Conduit SearchProtect has started disabling our DLL blocklist. Signatures like libinject and MovieMode are coming back. What can we do? Our usual approach doesn't work against a determined adversary.
- see questions/concerns below in beta section.
bug 1022742 crash in libc-2.11.1.so@0x2dad2 [ashughes]
- new as of 2014-06-06 across products/versions on Linux, caused by update from Canonical?
Beta
- bug 1022471 - Conduit SearchProtect disables the blocklist
- We were looking pretty good for 30 stability. But this bug is destabilizing 30. If the volume of crashes in libinject.dll returns to the level we had in early 30 betas, 30 is going to be the crashiest release we've put out in a while. :-(
- Do A/V vendors typically battle these sorts of things? If so, have we made them aware?
- If not, is there anything we can do to mitigate this without a respin, right now? Can we even turn around an RC build 3 in under 24 hours, if we had to? It doesn't seem prudent to try. Which leaves us putting out a point release with a fix that may be fleetingly effective at best.
Aurora
Trunk
- bug 1021053 - mozilla::ipc::MessageChannel::Send(IPC::Message*, IPC::Message*) - new, #1 top crash
- bug 1020835 - crash in DestroyBlobFunc - two top crash signature affected, fix pending approval
Android
- Crash rates look good
- Nightly is up mostly due to bug 1011474