Closed Bug 824299 Opened 12 years ago Closed 12 years ago

crash in mozilla::dom::FragmentOrElement::IsPurple

Categories

(Core :: DOM: Core & HTML, defect, P1)

ARM
All
defect

Tracking

()

RESOLVED DUPLICATE of bug 822398
blocking-basecamp +

People

(Reporter: m1, Assigned: smaug)

Details

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?
Flags: needinfo?(mvines)
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.
Flags: needinfo?(mvines)
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?
Assignee: nobody → bugs
Component: General → DOM: Core & HTML
Product: Boot2Gecko → Core
blocking-basecamp: ? → +
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.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.