958246 - [Monkey Test] Crash in mozilla::ScrollFrameHelper::AppendScrollPartsT

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P1)

Description

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Attachment: crash_logs_1.zip

This happens during monkey testing.

I attached 

1) logcats 
2) dmesg
3) Memory Usage
4) b2g_procrank usage logs

STR:

Test Steps:
1. Run Browser and call test case monkey script.
2. After day and night run ,mini dumps are generated in the phone.

Comment 1

[Mats Palmgren (inactive)]

The crash reason/address makes me think this would be exploitable:

Crash reason:  SIGILL
Crash address: 0xb57155a6

Thread 0 (crashed)
 0  libxul.so!mozilla::ScrollFrameHelper::AppendScrollPartsTo(nsDisplayListBuilder*, nsRect const&, nsDisplayListSet const&, bool&, bool) [nsIFrame.h : 1181 + 0x6]
     r4 = 0xaecf3960    r5 = 0xbecd8a1c    r6 = 0xbecd8a20    r7 = 0xb637a868
     r8 = 0x00000094    r9 = 0xacba68a0   r10 = 0xbecd9154    fp = 0x00000001
     sp = 0xbecd89f0    lr = 0xb5715413    pc = 0xb57155a6
    Found by: given as instruction pointer in context
 1  libxul.so!mozilla::ScrollFrameHelper::BuildDisplayList(nsDisplayListBuilder*, nsRect const&, nsDisplayListSet const&) [nsGfxScrollFrame.cpp : 2468 + 0xf]
     r4 = 0xbecd8b43    r5 = 0xbecd8c64    r6 = 0xaecf3960    r7 = 0xbecd9154
     r8 = 0x00000000    r9 = 0xbecd8f60   r10 = 0xbecd8cc8    fp = 0x00000000
     sp = 0xbecd8b28    pc = 0xb57159e7
    Found by: call frame info
 2  libxul.so!nsIFrame::BuildDisplayListForChild(nsDisplayListBuilder*, nsIFrame*, nsRect const&, nsDisplayListSet const&, unsigned int) [nsFrame.cpp : 2234 + 0xd]
     r4 = 0xaecf3910    r5 = 0xb5715a7f    r6 = 0x00000000    r7 = 0x00000000
     r8 = 0xbecd9154    r9 = 0xaecf3810   r10 = 0xaecf3298    fp = 0xaecf3298
     sp = 0xbecd8ca8    pc = 0xb570de9f
    Found by: call frame info
 3  libxul.so!ViewportFrame::BuildDisplayList(nsDisplayListBuilder*, nsRect const&, nsDisplayListSet const&) [nsViewportFrame.cpp : 70 + 0xf]
     r4 = 0xbecd9154    r5 = 0xaecf3298    r6 = 0xbecd8f60    r7 = 0xbecd8ec0
     r8 = 0xbecd9154    r9 = 0xaecf3188   r10 = 0x00000000    fp = 0x00000000
     sp = 0xbecd8e68    pc = 0xb5734275
    Found by: call frame info
 4  libxul.so!nsIFrame::BuildDisplayListForStackingContext(nsDisplayListBuilder*, nsRect const&, nsDisplayList*) [nsFrame.cpp : 1901 + 0xf]
     r4 = 0xbecd9154    r5 = 0xaecf3298    r6 = 0xbecd8f34    r7 = 0x00000000
     r8 = 0x00000000    r9 = 0xaecf3188   r10 = 0x00000000    fp = 0x00000000
     sp = 0xbecd8e90    pc = 0xb570d7e1
    Found by: call frame info
 5  libxul.so!nsLayoutUtils::PaintFrame(nsRenderingContext*, nsIFrame*, nsRegion const&, unsigned int, unsigned int) [nsLayoutUtils.cpp : 2207 + 0xb]
     r4 = 0xaecf3298    r5 = 0x00000000    r6 = 0x00000304    r7 = 0xb32c3c80
     r8 = 0x00000004    r9 = 0xaecf3910   r10 = 0xb637a868    fp = 0x00000000
     sp = 0xbecd9048    pc = 0xb56ea501
    Found by: call frame info
 6  libxul.so!PresShell::Paint(nsView*, nsRegion const&, unsigned int) [nsPresShell.cpp : 5845 + 0xd]
     r4 = 0xac4bb430    r5 = 0xb32c3c80    r6 = 0xaecf3298    r7 = 0xffffffff
     r8 = 0x00000000    r9 = 0xb0318800   r10 = 0x00000001    fp = 0xb637a868
     sp = 0xbecd9470    pc = 0xb56b8eff
    Found by: call frame info
 7  libxul.so!nsViewManager::ProcessPendingUpdatesForView(nsView*, bool) [nsViewManager.cpp : 421 + 0x15]
     r4 = 0xadfb5520    r5 = 0xadfb4600    r6 = 0x00000001    r7 = 0xb32c3c80
     r8 = 0xb56b8ce1    r9 = 0xb329b204   r10 = 0xfffffffc    fp = 0x00000000
     sp = 0xbecd9538    pc = 0xb5470a2d
    Found by: call frame info
 8  libxul.so!nsRefreshDriver::Tick(long long, mozilla::TimeStamp) [nsRefreshDriver.cpp : 1208 + 0x5]
...

Comment 2

[Mats Palmgren (inactive)]

(In reply to Tapas Kumar Kundu from comment #0)
> Test Steps:
> 1. Run Browser and call test case monkey script.

Sorry, I don't know what that means.

Comment 3

[Timothy Nikkel (:tnikkel)]

Short of steps knowing which exact line we are crashing on in AppendScrollPartsTo or nsIFrame.h would be helpful too, right now it's hard to tell, the exact revision that is being used to test would ensure the line numbers are the same.

Comment 4

[Jason Smith [:jsmith]]

(In reply to Mats Palmgren (:mats) from comment #2)
> (In reply to Tapas Kumar Kundu from comment #0)
> > Test Steps:
> > 1. Run Browser and call test case monkey script.
> 
> Sorry, I don't know what that means.

This is a monkey test bug, so we can't get additional information on this. It's confidential.

Comment 5

[Michael Vines [:m1] [:evilmachines]]

Tapas can give you the exact Gecko SHA1 that we found this bug on though (it's a stock FxOS v1.3 gecko)

Comment 6

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

"gecko" revision="3820ecddfe632a5595fea0cab8eb3651ab7bf0c6"
"gaia" revision="01e9da49be2cc4bc134eeefc434740d572ec2246"

Comment 7

[Timothy Nikkel (:tnikkel)]

So it looks like we crash making this GetFirstPrincipalChild() call here https://github.com/mozilla/gecko-dev/blob/3820ecddfe632a5595fea0cab8eb3651ab7bf0c6/layout/generic/nsGfxScrollFrame.cpp#L2110

So our mOuter frame got deleted somehow maybe?

Comment 8

[Mats Palmgren (inactive)]

I would expect a frame poison crash in that case, but it appears it's not:
FramePoisonBase=00000000f0dea000
Crash address: 0xb57155a6
(ScrollFrameHelper is embedded in the frame so mOuter should contain
poison when the frame is destroyed)

Also, mOuter is used on the first line in this method so it seems it
should have crashed there in that case?

Comment 9

[Mats Palmgren (inactive)]

Is the crash reproducible?
Does it always crash on 0xb57155a6?
Does it always crash in AppendScrollPartsTo?

Comment 10

[Michael Vines [:m1] [:evilmachines]]

(In reply to Mats Palmgren (:mats) from comment #9)
> Is the crash reproducible?
> Does it always crash on 0xb57155a6?
> Does it always crash in AppendScrollPartsTo?

We've observed this crash just once so far.

Comment 11

[Preeti Raghunath(:Preeti)]

Mats,

Please continue to investigate with priority.

Also, provide an ETA for the fix.

Comment 12

[Mats Palmgren (inactive)]

I don't think it's possible to fix this with the information given so far.
We need more data, or ideally steps-to-reproduce.

I don't want to speculate to much with so little data, but a plausible
guess is that someone clobbered the memory being used in AppendScrollPartsTo
(mOuter's vtable pointer).  Any code could have done that.

FTR, I read the source for the stack frames #0 #1 and #2 and it looks like
the GetChildList() call in GetFirstPrincipalChild() could be the first
virtual call on this frame in that path.

Comment 13

[Inder]

As Michael mentioned in comment 10 that we have seen this issue once. We will update when we see this issue again in our stability tests which are on going.

Comment 14

[Greg Grisco]

Closing since we've seen only one time two weeks ago.  Will re-open if we see this again.