Closed Bug 620937 Opened 11 years ago Closed 3 years ago

Crash [@ nsContentPermissionRequestProxy::GetElement] [@ nsContentPermissionRequestProxy::GetUri]


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




Tracking Status
fennec - ---


(Reporter: jdm, Unassigned)


(Keywords: crash, Whiteboard: [mobile-crash])

Crash Data

ID: a6d79116-3cf1-4d39-9247-051af2101221

Signature	nsContentPermissionRequestProxy::GetElement
UUID	a6d79116-3cf1-4d39-9247-051af2101221
Time 	2010-12-21 17:27:02.662861
Uptime	118
Last Crash	34854 seconds (9.7 hours) before submission
Install Age	34814 seconds (9.7 hours) since version was first installed.
Product	Fennec
Version	4.0b4pre
Build ID	20101220042014
Branch	2.0
OS	Linux
OS Version	0.0.0 Linux #1 PREEMPT Wed Dec 15 19:51:23 EST 2010 armv7l
CPU	arm
CPU Info	
Crash Reason	SIGSEGV
Crash Address	0x0
User Comments	
App Notes 	HTC Nexus One
Processor Notes 	
EMCheckCompatibility	False
Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	nsContentPermissionRequestProxy::GetElement 	dom/base/nsContentPermissionHelper.cpp:109
1 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/unix/xptcinvoke_arm.cpp:199
2 	XPCWrappedNative::CallMethod 	js/src/xpconnect/src/xpcwrappednative.cpp:3064
3 	XPC_WN_GetterSetter 	js/src/xpconnect/src/xpcprivate.h:2637
4 	js::Invoke 	js/src/jscntxtinlines.h:689
5 	js::ExternalGetOrSet 	js/src/jsinterp.cpp:858
6 	js_GetPropertyHelper 	js/src/jsobj.cpp:5054
7 	js::Interpret 	js/src/jsinterp.cpp:4156
8 	js::Invoke 	js/src/jsinterp.cpp:657
9 	js::ExternalInvoke 	js/src/jsinterp.cpp:858
10 	JS_CallFunctionValue 	js/src/jsinterp.h:962
11 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1694
12 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:589
13 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/unix/xptcstubs_arm.cpp:134
15 	nsContentPermissionRequestProxy::Init 	nsCOMPtr.h:492
16 		@0x505fe72f 	
17 	mozilla::dom::ContentPermissionRequestParent::Recvprompt 	dom/base/nsContentPermissionHelper.cpp:158
18 	mozilla::dom::PContentPermissionRequestParent::OnMessageReceived 	PContentPermissionRequestParent.cpp:107
19 	mozilla::dom::PContentParent::OnMessageReceived 	PContentParent.cpp:604
20 	mozilla::ipc::AsyncChannel::OnDispatchMessage 	ipc/glue/AsyncChannel.cpp:262
21 	mozilla::ipc::RPCChannel::OnMaybeDequeueOne 	ipc/glue/RPCChannel.cpp:440
22 	RunnableMethod<mozilla::ipc::RPCChannel, bool , Tuple0>::Run 	ipc/chromium/src/base/task.h:308
23 	mozilla::ipc::RPCChannel::DequeueTask::Run 	RPCChannel.h:475
24 	MessageLoop::RunTask 	ipc/chromium/src/base/
25 	MessageLoop::DeferOrRunPendingTask 	ipc/chromium/src/base/
26 	MessageLoop::DoWork 	ipc/chromium/src/base/
27 	mozilla::ipc::DoWorkRunnable::Run 	ipc/glue/MessagePump.cpp:71
28 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:626
29 	NS_ProcessNextEvent_P 	nsThreadUtils.cpp:250
30 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:134
31 	MessageLoop::RunInternal 	ipc/chromium/src/base/
32 	MessageLoop::Run 	ipc/chromium/src/base/
33 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:198
34 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:192
35 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3693
36 	GeckoStart 	toolkit/xre/nsAndroidStartup.cpp:131
So, we're hitting

>109  NS_ADDREF(*aRequestingElement = mParent->mElement);

when mElement is null.  Given that the only time mElement is set is in ContentPermissionRequestParent::ContentPermissionRequestParent:

>248   return new ContentPermissionRequestParent(type, mFrameElement, uri);

we've got a tabParent with a null frame element, ie. it's most likely been destroyed.
Severity: normal → critical
I expect that the GetURI crashes I see occasionally are the same root cause.
Summary: Crash [@ nsContentPermissionRequestProxy::GetElement] → Crash [@ nsContentPermissionRequestProxy::GetElement] [@ nsContentPermissionRequestProxy::GetURI]
Assignee: nobody → doug.turner
tracking-fennec: --- → 2.0+
OS: Mac OS X → All
Hardware: x86 → All
i can look soon.  jdm, steal if you want to.
I've been poking around, and I'm confused, especially in regards to the GetURI crashes.  The URI is sent from the content process, and corresponds to nsGeolocation::mURI.  That's retrieved from the document's node principal, and never changed until nsGeolocation::Shutdown, at which point it's nulled out.  If there's a null URI at the time we assign mURI, we bail.  The only way I can figure we'd end up with a null URI, therefore, is if we are calling RegisterRequestWithPrompt after Shutdown.
could this be called by an extension somehow?
Any time nsGeolocation::Update is called, if WindowOwnerStillExists returns
false, we call Shutdown.  Since mOwner must be non-null for
RegisterRequestForPrompt to succeed, that means that this block would return

>    PRBool closed = PR_FALSE;
>    window->GetClosed(&closed);
>    if (closed)
>      return PR_FALSE;
>    nsPIDOMWindow* outer = window->GetOuterWindow();
>    if (!outer || outer->GetCurrentInnerWindow() != window)
>      return PR_FALSE;

In regards to extensions, I don't see how that would make a difference.
Bug 627355 is also tracking the GetURI crash, but I'll leave it open until we conclusively prove they're the same issue.
Summary: Crash [@ nsContentPermissionRequestProxy::GetElement] [@ nsContentPermissionRequestProxy::GetURI] → Crash [@ nsContentPermissionRequestProxy::GetElement] [@ nsContentPermissionRequestProxy::GetUri]
Interestingly enough, not every GetUri crash is at 0x0.  There are a significant number of 0x12 crash addresses as well.
This crash doesn't appear to be happening very often per our crash reporting system, but would still love to see a fix
tracking-fennec: 2.0+ → 2.0-
Flags: in-testsuite-
Closed: 11 years ago
Resolution: --- → FIXED
Not fixed. We still see stacks like the one in comment 0.
Resolution: FIXED → ---
I wonder why we just don't call:

from the ContentPermissionRequestParent destructor instead of on ::ActorDestroy.
tracking-fennec: 2.0- → 2.0next+
tracking-fennec: 2.0next+ → 6+
tracking-fennec: 6+ → 7+
is this still showing up on crash-stats?
tracking-fennec: 7+ → 6+
Still there on 4.0.1, don't see it in 6.0a1 but that doesn't necessarily mean anything. I don't think we ever really saw the signature in nightlies.
ah.  that explains it.  I was looking at the nightly crashes.

ContentPermissionRequestParent owns (strong reference) a mElement,

ContentPermissionRequestParent::Recvprompt is called and we create a nsContentPermissionRequestProxy.  This new object is assigned to a nsCOMPtr and held onto for the life of ContentPermissionRequestParent.

Then we create a nsContentPermissionRequestProxy, passing aContentPermissionRequestParent pointer to the proxy.  The proxy holds onto this parent pointer with the assumption that the parent will exist as long as the proxy does.

Now, I think the nsContentPermissionRequestProxy object (mProxy) should exist as long as the parent does.  The only place where the state could be wacked is in ::Recvprompt().  Maybe we are oom, or maybe Init() is failing?  If that happens, mProxy would be valid, but its state not-so-much.

Alternatively, we can make mParent in nsContentPermissionRequestProxy hold a strong reference.  Then in ContentPermissionRequestParent::ActorDestroy clear the cycle.
Here's the stack we're looking at:


Presumably we're crashing on this line in ContentPermissionPrompt.js:

The corresponding URI crash that we're also seeing is presumably at or Actually, the second one is in a callback, so that's probably fixed by when we added the ActorDestroy last time we looked at this.

That means that when we're inside ContentPermissionPrompt.prompt, request should be valid, and request::mParent should definitely be valid since we shouldn't have had a chance to spin the event loop. Even if we did, the ActorDestroy should take care of any situation that would invalidate the pointer, and we check for NULL. Therefore, I can only conclude that we're inlining the addref call, and that one of ContentPermissionRequestParent::mElement or ContentPermissionRequestParent::mURI  are null.

This indicates that we're either sending a null URI over the wire, or mFrameElement in TabParent is null. That's as far as I've delved so far.
Crash Signature: [@ nsContentPermissionRequestProxy::GetElement] [@ nsContentPermissionRequestProxy::GetUri]
tracking-fennec: 6+ → -
Crash Signature: [@ nsContentPermissionRequestProxy::GetElement] [@ nsContentPermissionRequestProxy::GetUri] → [@ nsContentPermissionRequestProxy::GetElement] [@ nsContentPermissionRequestProxy::GetUri]
Assignee: doug.turner → nobody
Whiteboard: [mobile-crash]
I've seen this crash with FF12 beta on a Nexus S device running ICS.
It's reproducible for me when visiting
FF either crashes immediately, or once starting zooming into the page.
Even worse, a song being played in the background with Google Play Music stops. This is reproducible here.

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
Closing because no crash reported since 12 weeks.
Closed: 11 years ago3 years ago
Resolution: --- → WONTFIX
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.