It's #2 top crasher in the trunk and first appeared in 15.0a1/20120506. The regression range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0a48e6561534&tochange=94ce5f33a9ea Signature nsDOMWindowUtils::SetDisplayPortForElement More Reports Search UUID 2e8a2401-64f6-4449-bda5-f44682120507 Date Processed 2012-05-07 04:31:25 Uptime 478 Install Age 8.0 minutes since version was first installed. Install Time 2012-05-07 04:23:16 Product FennecAndroid Version 15.0a1 Build ID 20120506030520 Release Channel nightly OS Linux OS Version 0.0.0 Linux 188.8.131.52-Lionfish-1.8_Bright-SBC+ #1 PREEMPT Thu May 3 21:35:21 EDT 2012 armv7l Build Architecture arm Build Architecture Info Crash Reason SIGSEGV Crash Address 0x1c App Notes AdapterVendorID: supersonic, AdapterDeviceID: PC36100. AdapterDescription: 'Model: 'PC36100', Product: 'htc_supersonic', Manufacturer: 'HTC', Hardware: 'supersonic''. HTC PC36100 sprint/htc_supersonic/supersonic:2.3.3/GRI40/134969.1:user/release-keys EMCheckCompatibility True Frame Module Signature Source 0 libxul.so nsDOMWindowUtils::SetDisplayPortForElement nsFrameManagerBase.h:83 1 libxul.so NS_InvokeByIndex_P xpcom/reflect/xptcall/src/md/unix/xptcinvoke_arm.cpp:194 2 libxul.so XPCWrappedNative::CallMethod js/xpconnect/src/XPCWrappedNative.cpp:3102 3 libxul.so XPC_WN_CallMethod js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1553 4 libxul.so js::Interpret js/src/jscntxtinlines.h:426 5 libxul.so js::RunScript js/src/jsinterp.cpp:480 6 libxul.so js::Invoke js/src/jsinterp.cpp:540 7 libxul.so JS_CallFunctionValue js/src/jsapi.cpp:5448 8 libxul.so nsXPCWrappedJSClass::CallMethod js/xpconnect/src/XPCWrappedJSClass.cpp:1509 9 libxul.so nsXPCWrappedJS::CallMethod js/xpconnect/src/XPCWrappedJS.cpp:616 10 libxul.so PrepareAndDispatch xpcom/reflect/xptcall/src/md/unix/xptcstubs_arm.cpp:138 ... More reports at: https://crash-stats.mozilla.com/report/list?signature=nsDOMWindowUtils%3A%3ASetDisplayPortForElement
Dbaron, could this be yours?
Maybe http://hg.mozilla.org/mozilla-central/rev/fa94b7958cb4 is hitting the case where a pres shell has a null frame manager? That seems consistent with an 0x1c offset, but not so consistent with nsIPresShell providing a GetRootFrame method.
Created attachment 621551 [details] [diff] [review] add null check where I'm not supposed to need one
I was hitting this crash with: http://people.mozilla.org/~mwargers/fuzzing/cross_fuzz/linktocrossfuzz.html Tap on the 'godoe a whole set' button (make sure you have popup windows unblocked, btw) While the fuzz testing is going on, switch from portrait to landscape repeatedly.
Comment on attachment 621551 [details] [diff] [review] add null check where I'm not supposed to need one [Triage Comment]
https://hg.mozilla.org/integration/mozilla-inbound/rev/4b9a76ac2df3 (now that mozilla-inbound is open, which it wasn't earlier)
Martijn, could you check that this actually fixes your testcase?
There are still crashes in 15.0a1/20120508055912 where the patch has landed.
Ok, that might be me, I wasn't sure that build contained the fix.
(In reply to David Baron [:dbaron] from comment #2) > Maybe http://hg.mozilla.org/mozilla-central/rev/fa94b7958cb4 is hitting the > case where a pres shell has a null frame manager? That seems consistent > with an 0x1c offset, but not so consistent with nsIPresShell providing a > GetRootFrame method. Not sure what I was thinking, but now 0x1c looks consistent with just having a null pres-shell.
Created attachment 622347 [details] [diff] [review] null check the right thing
Just adding in some STR as I just hit this on mobile Nightly (05/09), google.com/reader, sign-in and rotate phone to landscape
https://crash-stats.mozilla.com/report/list?signature=nsDOMWindowUtils%3A%3ASetDisplayPortForElement shows crashes only from 2012-05-06 through 2012-05-10, so this looks fixed now.
Comment on attachment 622347 [details] [diff] [review] null check the right thing [Approval Request Comment] Regression caused by (bug #): bug 747231 User impact if declined: crashes Testing completed (on m-c, etc.): on mozilla-central, crash stats Risk to taking this patch (and alternatives if risky): very low, null check String changes made by this patch: none I'll merge the two patches in this bug when landing them on aurora.
Verified by crash stats.
(In reply to Kevin Brosnan [:kbrosnan] from comment #20) > Verified by crash stats. It has never happened in 14.0a2.
The case in comment 4 doesn't crash anymore in trunk. I verified that.