Crash seen during stability test. Crash reason: SIGSEGV Crash address: 0x7 Thread 0 (crashed) 0 libxul.so!mozilla::dom::FragmentOrElement::IsPurple [FragmentOrElement.h : 303 + 0x0] r4 = 0x445de8e0 r5 = 0x47df5700 r6 = 0x00000000 r7 = 0x00000000 r8 = 0x00000000 r9 = 0xbefbd6e4 r10 = 0xbefbe6e4 fp = 0xbefbe72c sp = 0xbefbd6d8 lr = 0x40c0d3df pc = 0x40bb0dda Found by: given as instruction pointer in context 1 libxul.so!ShouldClearPurple [FragmentOrElement.cpp : 1494 + 0x7] r4 = 0x445de8e0 r5 = 0x47df5700 r6 = 0x00000000 r7 = 0x00000000 r8 = 0x00000000 r9 = 0xbefbd6e4 r10 = 0xbefbe6e4 fp = 0xbefbe72c sp = 0xbefbd6d8 pc = 0x40c0d3df Found by: call frame info 2 libxul.so!mozilla::dom::FragmentOrElement::CanSkip [FragmentOrElement.cpp : 1607 + 0xb] r4 = 0x47d7f400 r5 = 0x47df5700 r6 = 0x00000000 r7 = 0x00000000 r8 = 0x00000000 r9 = 0xbefbd6e4 r10 = 0xbefbe6e4 fp = 0xbefbe72c sp = 0xbefbd6e0 pc = 0x40c0e931 Found by: call frame info 3 libxul.so!nsGenericDOMDataNode::cycleCollection::CanSkipImpl [nsGenericDOMDataNode.cpp : 68 + 0x3] r4 = 0x404621f8 r5 = 0x40462050 r6 = 0x4046205c r7 = 0x40466020 r8 = 0x00000000 r9 = 0x40466020 r10 = 0xbefbe738 fp = 0xbefbe72c sp = 0xbefbe710 pc = 0x40be2a1f Found by: call frame info 4 libxul.so!nsPurpleBuffer::RemoveSkippable [nsCycleCollectionParticipant.h : 262 + 0x1] r4 = 0x404621f8 r5 = 0x40462050 r6 = 0x4046205c r7 = 0x40466020 r8 = 0x00000000 r9 = 0x40466020 r10 = 0xbefbe738 fp = 0xbefbe72c sp = 0xbefbe718 pc = 0x4117497d Found by: call frame info 5 libxul.so!nsCycleCollector::ForgetSkippable [nsCycleCollector.cpp : 2109 + 0x9] r4 = 0x40462000 r5 = 0x00000001 r6 = 0x41158791 r7 = 0x0004d0ba r8 = 0xbefbe84f r9 = 0x40407c0c r10 = 0x00000000 fp = 0x00000000 sp = 0xbefbe768 pc = 0x4117566b Found by: call frame info 6 libxul.so!nsCycleCollector_forgetSkippable [nsCycleCollector.cpp : 3218 + 0x7] r4 = 0x41a0c508 r5 = 0x00000001 r6 = 0x17e5ca2e r7 = 0x0004d0ba r8 = 0xbefbe84f r9 = 0x40407c0c r10 = 0x00000000 fp = 0x00000000 sp = 0xbefbe780 pc = 0x4117569f Found by: call frame info 7 libxul.so!FireForgetSkippable [nsJSEnvironment.cpp : 3050 + 0x3] r4 = 0x000001e3 r5 = 0x00000001 r6 = 0x17e5ca2e r7 = 0x0004d0ba r8 = 0xbefbe84f r9 = 0x40407c0c r10 = 0x00000000 fp = 0x00000000 sp = 0xbefbe798 pc = 0x40ce962f Found by: call frame info 8 libxul.so!CCTimerFired [nsJSEnvironment.cpp : 3287 + 0x7] r4 = 0x41a07680 r5 = 0x00000001 r6 = 0x000001e3 r7 = 0x0000000e r8 = 0xbefbe84f r9 = 0x40407c0c r10 = 0x00000000 fp = 0x00000000 sp = 0xbefbe7b0 pc = 0x40ce9ccb Found by: call frame info 9 libxul.so!nsTimerImpl::Fire [nsTimerImpl.cpp : 473 + 0x5] r4 = 0x44e1d580 r5 = 0x40ce9c29 r6 = 0x00000002 r7 = 0x000002df r8 = 0xbefbe84f r9 = 0x40407c0c r10 = 0x00000000 fp = 0x00000000 sp = 0xbefbe7c8 pc = 0x4116f831 Found by: call frame info 10 libxul.so!nsTimerEvent::Run [nsTimerImpl.cpp : 556 + 0x5] r4 = 0x44e1d580 r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000001 r8 = 0xbefbe84f r9 = 0x40407c0c r10 = 0x00000000 fp = 0x00000000 sp = 0xbefbe800 pc = 0x4116f8eb Found by: call frame info 11 libxul.so!nsThread::ProcessNextEvent [nsThread.cpp : 620 + 0x5] r4 = 0x40407be0 r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000001 r8 = 0xbefbe84f r9 = 0x40407c0c r10 = 0x00000000 fp = 0x00000000 sp = 0xbefbe808 pc = 0x4116da23 Found by: call frame info 12 libxul.so!NS_ProcessNextEvent_P [nsThreadUtils.cpp : 220 + 0xb] r4 = 0x00000000 r5 = 0x404390c0 r6 = 0x404024d0 r7 = 0x00000001 r8 = 0x00000000 r9 = 0x40429000 r10 = 0x00000000 fp = 0x00000000 sp = 0xbefbe848 pc = 0x4114de3f Found by: call frame info 13 libxul.so!mozilla::ipc::MessagePump::Run [MessagePump.cpp : 82 + 0x7] r4 = 0x404024c0 r5 = 0x404390c0 r6 = 0x404024d0 r7 = 0x00000001 r8 = 0x00000000 r9 = 0x40429000 r10 = 0x00000000 fp = 0x00000000 sp = 0xbefbe858 pc = 0x4108582d Found by: call frame info 14 libxul.so!MessageLoop::RunInternal [message_loop.cc : 215 + 0x5] r4 = 0x404390c0 r5 = 0x4384d6a0 r6 = 0x40407be0 r7 = 0xbefbeafd r8 = 0x00000000 r9 = 0x40429000 r10 = 0x00000000 fp = 0x00000000 sp = 0xbefbe880 pc = 0x4118f179 Found by: call frame info 15 libxul.so!MessageLoop::Run [message_loop.cc : 208 + 0x5] r4 = 0x404390c0 r5 = 0x4384d6a0 r6 = 0x40407be0 r7 = 0xbefbeafd r8 = 0x00000000 r9 = 0x40429000 r10 = 0x00000000 fp = 0x00000000 sp = 0xbefbe888 pc = 0x4118f22f Found by: call frame info 16 libxul.so!nsBaseAppShell::Run [nsBaseAppShell.cpp : 163 + 0x7] r4 = 0x00000000 r5 = 0x4384d6a0 r6 = 0x40407be0 r7 = 0xbefbeafd r8 = 0x00000000 r9 = 0x40429000 r10 = 0x00000000 fp = 0x00000000 sp = 0xbefbe8a0 pc = 0x4100e359 Found by: call frame info 17 libxul.so!nsAppStartup::Run [nsAppStartup.cpp : 290 + 0x5] r4 = 0x438f0ac0 r5 = 0x41158791 r6 = 0x00000000 r7 = 0xbefbeafd r8 = 0x00000000 r9 = 0x40429000 r10 = 0x00000000 fp = 0x00000000 sp = 0xbefbe8b0 pc = 0x40f72075 Found by: call frame info 18 libxul.so!XREMain::XRE_mainRun [nsAppRunner.cpp : 3794 + 0x5] r4 = 0xbefbea0c r5 = 0x41158791 r6 = 0x00000000 r7 = 0xbefbeafd r8 = 0x00000000 r9 = 0x40429000 r10 = 0x00000000 fp = 0x00000000 sp = 0xbefbe8b8 pc = 0x409afe7b Found by: call frame info 19 libxul.so!XREMain::XRE_main [nsAppRunner.cpp : 3860 + 0x5] r4 = 0xbefbea0c r5 = 0xbefbe9e7 r6 = 0x00000000 r7 = 0xbefc0bf4 r8 = 0x40424000 r9 = 0x40429000 r10 = 0x00000000 fp = 0x00000000 sp = 0xbefbe9e0 pc = 0x409b2619 Found by: call frame info 20 libxul.so!XRE_main [nsAppRunner.cpp : 3935 + 0x3] r4 = 0x0001f180 r5 = 0xbefc0bf4 r6 = 0x00000001 r7 = 0x00000000 r8 = 0xbefbea0c r9 = 0x00000000 r10 = 0x00000000 fp = 0x00000000 sp = 0xbefbea08 pc = 0x409b2765 Found by: call frame info 21 b2g!main [nsBrowserApp.cpp : 164 + 0xf] r4 = 0x409b2719 r5 = 0x00000000 r6 = 0x00000001 r7 = 0xbefc0bf4 r8 = 0x00000000 r9 = 0x00000000 r10 = 0x00000000 fp = 0x00000000 sp = 0xbefbeb18 pc = 0x0000a11f Found by: call frame info 22 libc.so!__libc_init [libc_init_dynamic.c : 114 + 0x7] r4 = 0x00009ec4 r5 = 0xbefc0bf4 r6 = 0x00000001 r7 = 0xbefc0bfc r8 = 0x00000000 r9 = 0x00000000 r10 = 0x00000000 fp = 0x00000000 sp = 0xbefc0bd8 pc = 0x400b2a77 Found by: call frame info 23 libc.so!__cxa_atexit [atexit.c : 99 + 0x3] r4 = 0x00000000 r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000000 r8 = 0x00000000 r9 = 0x00000000 r10 = 0x00000000 fp = 0x00000000 sp = 0xbefc0bf0 pc = 0x400bb437 Found by: call frame info 24 0xbefc0db3 r4 = 0x00000000 r5 = 0xbefc0d03 r6 = 0xbefc0d15 r7 = 0xbefc0d28 r8 = 0xbefc0d4b r9 = 0xbefc0d64 r10 = 0xbefc0d81 fp = 0x00000000 sp = 0xbefc0c18 pc = 0xbefc0db5 Found by: call frame info

Michael, can you provide more information about the test case that can be used to reproduce this crash?

Test Steps: 1. Make MO calls and do video streaming. 2. Repeat step1 3 to 4 times. 3. Make a MO call. 4. When call is in progress, do airplane mode on and off.

Johnny, can you put this in the right product/component?

This is likely a bug somewhere other than where this stack points to. Bugs that show up in the cycle collector usually mean someone leaves dangling pointers hanging around and the cycle collector just happens to be the first code to touch it. I wouldn't be surprised if this is related to bug 824295.

Olli, can you help interpret what might be going on here in this cycle collector optimization code? If this looks like something that you're not the right owner for, feel free to hand back to nobody for re-triage of owner, or assign to someone else if you know who should work on this. I'm going to move this to core DOM, but this may of course be triggered by memory corruption in something entirely unrelated as well. But we need to start somewhere. Michael, do you know what gecko revision the crash in comment 0 happened with?

The original crash is a null deref, which suggests that either the FragmentOrElement is null, or that NS_CCAR_TAGGED_TO_PURPLE_ENTRY(mTagged) on the element's refcount is null.

(I don't know what is MO call.) Yeah, looks very much like a null pointer crash. Is it possible that we're running out of memory? Michael, do you know the build changeset from which you get the stack trace? Various 0x<small number> look a bit odd. null + offset. Do we have null pointer somewhere higher up in the stack.

Crash came from this version of Gecko (beta branch from about 17 days ago): https://github.com/mozilla/mozilla-central/commit/03d02d8d7e67ebdaebeacc73550adba5ca70c7d4 I looked at logcat for the crash and saw nothing remarkable around the crash event. The first gecko process just quit without much fanfare and another started up. No memory pressure events near the event (although some did occur earlier in the log). We've only captured this crash this one time BTW. I've asked our test folks to try to run the scenario again as soon as possible (hopefully before the new year) and will report back if we can catch it again.

We captured another "unhappy GC" crash today (once) @ -- 0xbee6b744: libxul.so!js::GC [Statistics.h : 172 + 0x1] 0xbee6b76c: libxul.so!js::GCForReason [jsfriendapi.cpp : 161 + 0x1] 0xbee6b774: libxul.so!nsJSContext::GarbageCollectNow [sps_sampler.h : 183 + 0x1] 0xbee6b794: libxul.so!nsMemoryPressureObserver::Observe [nsJSEnvironment.cpp : 245 + 0x1] 0xbee6b79c: libxul.so!nsMemoryPressureObserver::Observe [nsJSEnvironment.cpp : 250 + 0x1] 0xbee6b7ac: libxul.so!nsObserverList::NotifyObservers [nsVoidArray.h : 37 + 0x1] 0xbee6b7cc: libxul.so!nsObserverService::NotifyObservers [nsTHashtable.h : 148 + 0x1] 0xbee6b7d4: libxul.so!nsObserverService::NotifyObservers [nsObserverService.cpp : 141 + 0x1] 0xbee6b7e4: libxul.so!MemoryPressureRunnable::Run [nsTSubstring.h : 85 + 0x1] 0xbee6b804: libxul.so!nsThread::ProcessNextEvent [nsThread.cpp : 620 + 0x7] 0xbee6b844: libxul.so!NS_ProcessNextEvent_P [nsError.h : 1069 + 0x1] -- However this particular run was a bloodbath. We also saw bug 823951 and bug 700594 manifest multiple times. logcat is 100MB, lmk if you want it.

Comment 8 has probably nothing to do with this bug. This is about CC (cycle collection), comment 8 is about GC (garbage collection). But, both stacks could indicate some memory corruption.

This may or may not be bug 822398, but mass-closing so that we can get better resolution on crashes that still reproduce.