Closed Bug 749816 Opened 8 years ago Closed 8 years ago

crash in epoll_wait after changing display: table-column style to display:none on body

Categories

(Firefox for Android :: General, defect, critical)

ARM
Android
defect
Not set
critical

Tracking

()

VERIFIED FIXED
Firefox 15
Tracking Status
firefox14 --- fixed
firefox15 --- verified
blocking-fennec1.0 --- +

People

(Reporter: martijn.martijn, Assigned: tnikkel)

Details

(Keywords: crash, testcase, Whiteboard: [native-crash])

Crash Data

Attachments

(2 files)

Attached file testcase
See testcase, it crash current Fennec Native trunk build after 1 second or so on the Samsung Galaxy SII.

This bug was filed from the Socorro interface and is 
report bp-cde9f98c-4ef0-4a80-8ce5-8384f2120427 .
============================================================= 
0 	libc.so 	epoll_wait 	
1 	libutils.so 	_ZN7android6Looper9pollInnerEi 	
2 	libutils.so 	_ZN7android6Looper8pollOnceEiPiS1_PPv 	
3 	libandroid_runtime.so 	_ZN7android18NativeMessageQueue8pollOnceEi 	
4 	libandroid_runtime.so 	_ZN7android18NativeMessageQueue8pollOnceEi 	
5 	libdvm.so 	dvmPlatformInvoke 	
6 	libdvm.so 	dvmCallJNIMethod_virtualNoRef 	
7 	libdvm.so 	dvmAsmSisterStart 	
8 	libdvm.so 	dvmMterpStd 	
9 	libdvm.so 	dvmInterpret 	
10 	libdvm.so 	dvmInvokeMethod 	
11 	libdvm.so 	dvmFreeDexOrJar 	
12 	libdvm.so 	dvmAsmSisterStart 	
13 	libdvm.so 	dvmMterpStd 	
14 	libdvm.so 	dvmInterpret 	
15 	libdvm.so 	dvmCallMethodV
etc..
Whiteboard: [native-crash]
Hardware: All → ARM
Um. I would notnotnot expect this to be a reproduceable crash, and it's doubly confusing to have us nowhere in the crash stack. Layout gods?
blocking-fennec1.0: ? → +
Assignee: nobody → tnikkel
At http://mxr.mozilla.org/mozilla-central/source/dom/base/nsDOMWindowUtils.cpp#362 in nsDOMWindowUtils::SetDisplayPortForElement we call nsLayoutUtils::PaintFrame with an emply dirty region to flush retained layers. We added this in bug 693930 to stop keeping around retained layer contents for hidden tabs in XUL e10s Fennec.

But in this case we call PaintFrame with a null rendering context and the root frame of whatever document contains the element with the display port being set, in this case the content document. This fails because the frame doesn't have widget to paint to, so we have no where to paint. But we started a transaction and nsDisplayList::PaintForFrame bails without ending a transaction in this error state.
Attached patch patchSplinter Review
This makes us only call PaintFrame when we should. And fixes the crash. There still seems to be some painting weirdness, but I think that is an independent issue and is less important.

We could also make the error handling better in nsLayoutUtils::PaintFrame/nsDisplayList::PaintForFrame. But we should take this patch anyway.
Attachment #619750 - Flags: review?(roc)
https://hg.mozilla.org/mozilla-central/rev/a08a9656ef8c
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 15
Comment on attachment 619750 [details] [diff] [review]
patch

Mobile release blocker.
Attachment #619750 - Flags: approval-mozilla-aurora?
I'm still crashing with the stacktrace from bug 749915.
But this crash isn't happening anymore in current trunk build, so marking verified.
Status: RESOLVED → VERIFIED
Comment on attachment 619750 [details] [diff] [review]
patch

Correctness fix that fixes a crash.
Attachment #619750 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.