Nick, please look into this when you're done with generation and reviews.
Status: NEW → ASSIGNED
Priority: -- → P2
Priority: P2 → P4
(In reply to TinderboxPushlog Robot from comment #4) > RyanVM > https://tbpl.mozilla.org/php/getParsedLog.php?id=24107282&tree=Mozilla- > Inbound > Android 4.0 Panda mozilla-inbound opt test mochitest-gl on 2013-06-13 > 08:25:50 > revision: f9e6eb0d5239 > slave: panda-0785 > > PROCESS-CRASH | remoteautomation.py | application crashed [@ libc.so + > 0x23226] This log doesn't mention testOrderedBroadcast. Which supports my claim that this has nothing to do with these tests, and is truly intermittent. In fact, testOrderedBroadcast is in rc1 or rc2, and this was gl!
(In reply to TinderboxPushlog Robot from comment #6) > RyanVM > https://tbpl.mozilla.org/php/getParsedLog.php?id=24181738&tree=Mozilla- > Central > Android 4.0 Panda mozilla-central opt test mochitest-1 on 2013-06-14 19:57:50 > revision: 05d9196b27a1 > slave: panda-0765 > > PROCESS-CRASH | remoteautomation.py | application crashed [@ libc.so + > 0x23226] This log is during mochitest-1 (and therefore doesn't mention testOrderedBroadcast). RyanVM, can you update the title of this bug to be whatever you feel is more appropriate?
Assignee: nalexander → nobody
Component: Client: Android → General
Product: Firefox Health Report → Firefox for Android
Summary: Intermittent testOrderedBroadcast | application crashed [@ libc.so + 0x23226] → Intermittent Android remoteautomation.py, testOrderedBroadcast | application crashed [@ libc.so + 0x23226]
I am not sure that all of the crashes reported here are related, but some of the more recent ones have similar crash stacks. Comment 10 has: - 5 libxul.so!UTCToLocalStandardOffsetSeconds [DateTime.cpp:a0fa8c9992a5 : 19 + 0x9] - sp = 0x68fffbe0 pc = 0x6359e45d - Found by: stack scanning - 6 libxul.so!js::DateTimeInfo::updateTimeZoneAdjustment() [DateTime.cpp:a0fa8c9992a5 : 136 + 0x3] - r4 = 0x65c466a0 sp = 0x68fffc20 pc = 0x6359e511 - Found by: call frame info - 7 libxul.so!JSCompartment::init(JSContext*) [jscompartment.cpp:a0fa8c9992a5 : 97 + 0xb] - r4 = 0x65c466a0 r5 = 0x68df9530 r6 = 0x69223400 sp = 0x68fffc30 - pc = 0x6342e021 - Found by: call frame info - 8 libxul.so!js::NewCompartment(JSContext*, JS::Zone*, JSPrincipals*, JS::CompartmentOptions const&) [jsgc.cpp:a0fa8c9992a5 : 4739 + 0x7] - r4 = 0x65c466a0 r5 = 0x68df9530 r6 = 0x69223400 sp = 0x68fffc40 - pc = 0x6344ca31 - Found by: call frame info - 9 libxul.so!JS_NewGlobalObject(JSContext*, JSClass*, JSPrincipals*, JS::CompartmentOptions const&) [jsapi.cpp:a0fa8c9992a5 : 3344 + 0x7] - r4 = 0x68df9530 r5 = 0x68fffcb0 r6 = 0x684bc000 r7 = 0x63c7deb0 - r8 = 0x63c02fb4 r9 = 0x6851a65c r10 = 0x6851a400 sp = 0x68fffc68 - pc = 0x634135fd - Found by: call frame info - 10 libxul.so!mozilla::dom::workers::CreateDedicatedWorkerGlobalScope(JSContext*) [WorkerScope.cpp:a0fa8c9992a5 : 981 + 0x11] - r4 = 0x68df9530 r5 = 0x68df9530 r6 = 0x68df9530 r7 = 0x5be48cd8 - r8 = 0x63c02fb4 r9 = 0x6851a65c r10 = 0x6851a400 sp = 0x68fffc88 - pc = 0x62df0987 - Found by: call frame info Comment 11 is very similar. In both failures, UTCToLocalStandardOffsetSeconds is being called in JSCompartment::init in 2 threads. :bhackett -- could you look at this? (I'm not familiar with this code and I see you have been active in jscompartment.cpp.)
These crashes seem to consistently be under the localtime_r library call in ComputeLocalTime under UTCToLocalStandardOffsetSeconds, at least going by the stacks. Very strange, we're definitely not passing any corrupt data in. This doesn't seem to have anything to do with compartment code.
Closing bugs where TBPLbot has previously commented, but have now not been modified for >3 months & do not contain the whiteboard strings for disabled/annotated tests or use the keyword leave-open. Filter on: mass-intermittent-bug-closure-2014-07
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.