897872 - crash in mozilla::dom::ContentParent::RecvAddGeolocationListener

Status: VERIFIED FIXED

(Core :: DOM: Geolocation, defect)

Description

[Scoobidiver (away)]

It first showed up in 25.0a1/20130724. The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5ceea82a79c7&tochange=2983ca6d4d1a
It might be a regression from bug 884061.

Signature 	mozilla::dom::ContentParent::RecvAddGeolocationListener(IPC::Principal const&, bool const&) More Reports Search
UUID 	5ce72825-4470-47dc-92c1-1f9092130724
Date Processed	2013-07-24 20:44:19.416076
Uptime	17219
Last Crash	362747 seconds before submission
Install Age 	23012 since version was first installed.
Install Time 	2013-07-24 14:20:38
Product 	Firefox
Version 	25.0a1
Build ID 	20130724030204
Release Channel 	nightly
OS 	Mac OS X
OS Version 	10.8.4 12E55
Build Architecture 	amd64
Build Architecture Info 	family 6 model 42 stepping 7 | 4
Crash Reason 	EXC_BAD_ACCESS / KERN_INVALID_ADDRESS
Crash Address 	0x0
App Notes 	
AdapterVendorID: 0x8086, AdapterDeviceID: 0x 126GL Layers! GL Context? GL Context+ GL Layers+ 

Frame 	Module 	Signature 	Source
0 	XUL 	mozilla::dom::ContentParent::RecvAddGeolocationListener(IPC::Principal const&, bool const&) 	dom/ipc/ContentParent.cpp
1 	XUL 	mozilla::dom::PContentParent::OnMessageReceived(IPC::Message const&) 	/builds/slave/m-in-osx64-0000000000000000000/build/obj-firefox/x86_64/ipc/ipdl/PContentParent.cpp
2 	XUL 	mozilla::ipc::AsyncChannel::OnDispatchMessage(IPC::Message const&) 	ipc/glue/AsyncChannel.cpp
3 	XUL 	mozilla::ipc::RPCChannel::OnMaybeDequeueOne() 	ipc/glue/RPCChannel.cpp
4 	XUL 	MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&) 	/builds/slave/m-in-osx64-0000000000000000000/build/obj-firefox/x86_64/ipc/chromium/../../../../ipc/chromium/src/base/message_loop.cc
5 	XUL 	MessageLoop::DoWork() 	/builds/slave/m-in-osx64-0000000000000000000/build/obj-firefox/x86_64/ipc/chromium/../../../../ipc/chromium/src/base/message_loop.cc
6 	XUL 	mozilla::ipc::DoWorkRunnable::Run() 	/builds/slave/m-in-osx64-0000000000000000000/build/obj-firefox/x86_64/ipc/glue/../../../../ipc/glue/MessagePump.cpp
7 	XUL 	nsThread::ProcessNextEvent(bool, bool*) 	/builds/slave/m-in-osx64-0000000000000000000/build/obj-firefox/x86_64/xpcom/threads/../../../../xpcom/threads/nsThread.cpp
8 	XUL 	NS_ProcessPendingEvents(nsIThread*, unsigned int) 	/builds/slave/m-in-osx64-0000000000000000000/build/obj-firefox/x86_64/xpcom/build/nsThreadUtils.cpp
9 	XUL 	nsBaseAppShell::NativeEventCallback() 	/builds/slave/m-in-osx64-0000000000000000000/build/obj-firefox/x86_64/widget/xpwidgets/../../../../widget/xpwidgets/nsBaseAppShell.cpp
10 	XUL 	nsAppShell::ProcessGeckoEvents(void*) 	/builds/slave/m-in-osx64-0000000000000000000/build/obj-firefox/x86_64/widget/cocoa/../../../../widget/cocoa/nsAppShell.mm
11 	CoreFoundation 	CoreFoundation@0x12b31 	
...

More reports at:
https://crash-stats.mozilla.com/report/list?product=Firefox&signature=mozilla%3A%3Adom%3A%3AContentParent%3A%3ARecvAddGeolocationListener%28IPC%3A%3APrincipal+const%26%2C+bool+const%26%29

Comment 1

[Josh Matthews [:jdm]]

Why are we running content processes on desktop Firefox? I don't understand how this could come about.

Comment 2

[Benjamin Smedberg]

We're running content processes to produce tab previews now in Firefox desktop.

Comment 3

[Josh Matthews [:jdm]]

Oh, ha. That's right. Bleah, so how should we special case desktop where we don't care if we don't have an app, versus b2g where we want to fail the operation if one isn't present?

Comment 4

[Josh Matthews [:jdm]]

I guess we could throw a MOZ_WIDGET_GONK ifdef in there :/

Comment 5

[Doug Turner (:dougt)]

for now, sure.  but the ff e10s folks will probably hit the same problem, right?

Comment 6

[:Gavin Sharp [email: [e-mail]]]

This is the FF e10s folks hitting that problem. Tom filed bug 900707 to track issues of this problem in general, we should just fix that somehow.

Comment 7

[Jonathan Protzenko [:protz]]

This would make Firefox crash two seconds after startup, every time. Workaround is to shut off network (to prevent the background service from trying to generate a new thumbnail), open the new tab dialog, and restore / remove thumbnails until you reach a subset of nine websites all of which do not trigger the bug.

Comment 8

[Mark Hammond [:markh] [:mhammond]]

I'm guessing the crash might be this block:

      nsCOMPtr<mozIApplication> app = tab->GetOwnOrContainingApp();
      uint32_t appId;
      app->GetLocalId(&appId);

and that GetOwnOrContainingApp() can return NULL.  So wouldn't it be a viable short-term fix to not dereference the NULL pointer - something like:

      nsCOMPtr<mozIApplication> app = tab->GetOwnOrContainingApp();
      if (!app) {
        continue;
      }

which will just decline the permission check, and a followup can determine what the correct behaviour actually is for desktop?

Comment 9

[:Gavin Sharp [email: [e-mail]]]

Hmm, yes! I thought this would be fixed by bug 900707, but it looks like it's actually unrelated...

Comment 10

[Drew Willcoxon :adw]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #9)
> Hmm, yes! I thought this would be fixed by bug 900707, but it looks like
> it's actually unrelated...

That looks right, though.  That bug added a big #ifdef MOZ_CHILD_PERMISSIONS around most of the body of ContentParent::RecvAddGeolocationListener: http://mxr.mozilla.org/mozilla-central/source/dom/ipc/ContentParent.cpp#3016

MOZ_CHILD_PERMISSIONS is only set for b2g: http://mxr.mozilla.org/mozilla-central/source/configure.in#5605

So Mark's comment 8 might have been right before that, but now I don't see how desktop could crash here anymore.  crash-stats says the last crash was on 25.

Comment 11

[Drew Willcoxon :adw]

I talked to Gavin and he agrees, so resolving as fixed by bug 900707.

Comment 12

[Mihai Morar, (:MihaiMorar)]

I am not able to reproduce this issue on Latest Aurora 26. I also see only one crash on Windows 7 and one on Mac OSX in last month in Soccoro:

https://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&reason_type=contains&date=2013-10-22&range_value=28&range_unit=days&hang_type=any&process_type=any&signature=mozilla%3A%3Adom%3A%3AContentParent%3A%3ARecvAddGeolocationListener%28IPC%3A%3APrincipal+const%26%2C+bool+const%26%29

Marking as verified based on the stats mentioned above.