1342711 - crash in nsDisplayList::PaintRoot if breakpoint set

Status: NEW

(Core :: Graphics: Layers, defect, P3)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Firefox Nightly 54.0a1 20170225 (32-bit) on Windows 8.1 64-bit (Nvidia 765M, Intel 4600HD 10.18.14.4578)

By using a breakpoint in places ui code, it's possible to reliably crash Firefox.

Steps to reproduce:
1. Visit a page in Nightly so something is in its history.
2. Open menu "History" > "Show All History"
3. Open menu "Tools" > "Web developer" > "Toggle Tools"
4. Click the gear icon on the right.
5. Enable "browsr chrome & addon debugging" and "remote debugging".
6. Open menu "Tools" > "Web developer" > "Browser Toolbox" and confirm the connection.
7. Switch to debugger.
8. In the search box, search for "PlacesUtils.jsm" and select it.
9. Go to line 481 and set a breakpoint on the line with the only statement in nodeIsURI by clicking on the line number. Current code:
>  nodeIsURI: function PU_nodeIsURI(aNode) {
>    return aNode.type == Ci.nsINavHistoryResultNode.RESULT_TYPE_URI;
>  },
10. Don't have the debugger maximized but the Places window in the background.
11. Move the mouse over one of history items.
Actual result: Breakpoint gets triggered (if I remember correct, it crashed now once).
12. Use the "Step over" button until the execution switches to the caller of the method, then let the script continue.
If 12) doesn't crash it , go back to 11) - it crashed twice on first try (maybe because of multiselection?) and once maybe on the 5th or 6th one.

Crash reports:
https://crash-stats.mozilla.com/report/index/80c32248-5898-4731-a7da-e581c2170225
https://crash-stats.mozilla.com/report/index/51f41d18-c715-43d2-a666-d1f842170225
https://crash-stats.mozilla.com/report/index/80509a11-3b40-4b7b-9b67-fc1702170225

Comment 1

[Ryan Hunt [:rhunt]]

Ran this in debug and was able to reproduce. Here is the assert and stack trace I got.

It seems like JS is getting into a nested event loop which causes a paint, but we're already in a paint?

      MOZ_ASSERT(mPresContext->mLayoutPhaseCount[eLayoutPhase_Paint] == 0,
                 "recurring into paint");

 	xul.dll!nsAutoLayoutPhase::Enter() Line 35	C++
 	xul.dll!nsAutoLayoutPhase::nsAutoLayoutPhase(nsPresContext * aPresContext, nsLayoutPhase aPhase) Line 21	C++
 	xul.dll!mozilla::PresShell::Paint(nsView * aViewToPaint, const nsRegion & aDirtyRegion, unsigned int aFlags) Line 6370	C++
 	xul.dll!nsViewManager::ProcessPendingUpdatesPaint(nsIWidget * aWidget) Line 483	C++
 	xul.dll!nsViewManager::ProcessPendingUpdatesForView(nsView * aView, bool aFlushDirtyRegion) Line 411	C++
 	xul.dll!nsViewManager::ProcessPendingUpdates() Line 1105	C++
 	xul.dll!nsRefreshDriver::Tick(__int64 aNowEpoch, mozilla::TimeStamp aNowTime) Line 2061	C++
 	xul.dll!mozilla::RefreshDriverTimer::TickDriver(nsRefreshDriver * driver, __int64 jsnow, mozilla::TimeStamp now) Line 330	C++
 	xul.dll!mozilla::RefreshDriverTimer::TickRefreshDrivers(__int64 aJsNow, mozilla::TimeStamp aNow, nsTArray<RefPtr<nsRefreshDriver> > & aDrivers) Line 301	C++
 	xul.dll!mozilla::RefreshDriverTimer::Tick(__int64 jsnow, mozilla::TimeStamp now) Line 323	C++
 	xul.dll!mozilla::VsyncRefreshDriverTimer::RunRefreshDrivers(mozilla::TimeStamp aTimeStamp) Line 738	C++
 	xul.dll!mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::TickRefreshDriver(mozilla::TimeStamp aVsyncTimestamp) Line 653	C++
 	xul.dll!mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::ParentProcessVsyncNotifier::Run() Line 501	C++
 	xul.dll!nsThread::ProcessNextEvent(bool aMayWait, bool * aResult) Line 1265	C++
 	xul.dll!NS_ProcessNextEvent(nsIThread * aThread, bool aMayWait) Line 389	C++
	xul.dll!mozilla::jsinspector::nsJSInspector::EnterNestedEventLoop(JS::Handle<JS::Value> requestor, unsigned int * out) Line 78	C++
 	xul.dll!XPTC__InvokebyIndex() Line 99	Unknown
 	xul.dll!CallMethodHelper::Call() Line 1331	C++
 	xul.dll!XPCWrappedNative::CallMethod(XPCCallContext & ccx, XPCWrappedNative::CallMode mode) Line 1296	C++
 	xul.dll!XPC_WN_CallMethod(JSContext * cx, unsigned int argc, JS::Value * vp) Line 983	C++
 	xul.dll!js::CallJSNative(JSContext * cx, bool(*)(JSContext *, unsigned int, JS::Value *) native, const JS::CallArgs & args) Line 282	C++
 	xul.dll!js::InternalCallOrConstruct(JSContext * cx, const JS::CallArgs & args, js::MaybeConstruct construct) Line 448	C++
 	xul.dll!Interpret(JSContext * cx, js::RunState & state) Line 2954	C++
 	xul.dll!js::RunScript(JSContext * cx, js::RunState & state) Line 394	C++
 	xul.dll!js::InternalCallOrConstruct(JSContext * cx, const JS::CallArgs & args, js::MaybeConstruct construct) Line 466	C++
 	xul.dll!js::Call(JSContext * cx, JS::Handle<JS::Value> fval, JS::Handle<JS::Value> thisv, const js::AnyInvokeArgs & args, JS::MutableHandle<JS::Value> rval) Line 512	C++
 	xul.dll!js::jit::InvokeFunction(JSContext * cx, JS::Handle<JSObject *> obj, bool constructing, unsigned int argc, JS::Value * argv, JS::MutableHandle<JS::Value> rval) Line 114	C++
 	[External Code]

Comment 2

[Ryan Hunt [:rhunt]]

Does this callstack make any sense, can JS run during a paint?

Comment 3

[Markus Stange [:mstange]]

The interesting part of the stack is cut off, unfortunately.

Maybe nodeIsURI is called during tree view painting. XUL trees have traditionally been the only thing that could call into JS during painting, but I was under the impression that this had been fixed.