700124 - Attempting to use JNI in child process [@ mozilla::AndroidBridge::EnsureJNIThread]

Status: RESOLVED FIXED

Description

[Josh Matthews [:jdm]]

This bug was filed from the Socorro interface and is 
report bp-dab1a704-3c13-4109-8c6c-349c12111106 .
============================================================= 

Here's some craziness: we're using the JNI to retrieve driver information for GfxInfo, but that's called from the content process.

0 	libxul.so 	mozilla::AndroidBridge::EnsureJNIThread 	widget/src/android/AndroidBridge.cpp:239
1 	libxul.so 	mozilla::AndroidBridge::AutoLocalJNIFrame::AutoLocalJNIFrame 	widget/src/android/AndroidBridge.h:105
2 	libxul.so 	mozilla::AndroidBridge::GetStaticStringField 	widget/src/android/AndroidBridge.cpp:856
3 	libxul.so 	mozilla::widget::GfxInfo::GetAdapterVendorID 	widget/src/android/GfxInfo.cpp:192
4 	libxul.so 	mozilla::widget::GfxInfoBase::GetFeatureStatusImpl 	widget/src/xpwidgets/GfxInfoBase.cpp:597
5 	libxul.so 	mozilla::widget::GfxInfo::GetFeatureStatusImpl 	widget/src/android/GfxInfo.cpp:321
6 	libxul.so 	mozilla::widget::GfxInfoBase::GetFeatureStatus 	widget/src/xpwidgets/GfxInfoBase.cpp:574
7 	libxul.so 	mozilla::WebGLContext::SetDimensions 	content/canvas/src/WebGLContext.cpp:616
8 	libxul.so 	nsHTMLCanvasElement::UpdateContext 	content/html/content/src/nsHTMLCanvasElement.cpp:622
9 	libxul.so 	nsHTMLCanvasElement::GetContext 	content/html/content/src/nsHTMLCanvasElement.cpp:540
10 	libxul.so 	nsIDOMHTMLCanvasElement_GetContext 	obj-firefox/js/xpconnect/src/dom_quickstubs.cpp:18716
11 	libxul.so 	js::InvokeKernel 	js/src/jscntxtinlines.h:297
12 	libxul.so 	js::Interpret 	js/src/jsinterp.cpp:3948
13 	libxul.so 	js::RunScript 	js/src/jsinterp.cpp:584
14 	libxul.so 	js::Execute 	js/src/jsinterp.cpp:783
15 	libxul.so 	JS_EvaluateUCScriptForPrincipalsVersion 	js/src/jsapi.cpp:5038
16 	libxul.so 	nsJSContext::EvaluateString 	dom/base/nsJSEnvironment.cpp:1490
17 	libxul.so 	nsScriptLoader::EvaluateScript 	content/base/src/nsScriptLoader.cpp:905
18 	libxul.so 	nsScriptLoader::ProcessRequest 	content/base/src/nsScriptLoader.cpp:799
19 	libxul.so 	nsScriptLoader::ProcessPendingRequests 	content/base/src/nsScriptLoader.cpp:948
20 	libxul.so 	nsScriptLoader::OnStreamComplete 	content/base/src/nsScriptLoader.cpp:1182
21 	libxul.so 	nsStreamLoader::OnStopRequest 	netwerk/base/src/nsStreamLoader.cpp:125
22 	libxul.so 	nsHTTPCompressConv::OnStopRequest 	netwerk/streamconv/converters/nsHTTPCompressConv.cpp:127
23 	libxul.so 	mozilla::net::HttpChannelChild::OnStopRequest 	netwerk/protocol/http/HttpChannelChild.cpp:484

Comment 1

[Josh Matthews [:jdm]]

This is killing Fennec nightly on every use of a canvas element. We should either back out the Android changes or properly serialize the relevant information in the parent and send it on process creation.

Comment 2

[Josh Matthews [:jdm]]

And when I say canvas, I really mean webgl canvas. Still, this is a topcrash.

Comment 3

[Benoit Jacob [:bjacob] (mostly away)]

Created attachment 572313 [details] [diff] [review]
avoid calling GfxInfoBase::GetFeatureStatusImpl for now on Android

this should remove this crash, according to the call stack.

So... if we can't use this interface to query hardware information in the content process on Android, what do you think we should do to get that infomation? Query it from the chrome process and pipe it to the content process?

Comment 4

[Josh Matthews [:jdm]]

I think the best plan would be to query and send the information in the chrome process inside ContentParent::ContentParent, and keep it all under an #ifdef ANDROID.

Comment 5

[Benoit Jacob [:bjacob] (mostly away)]

http://hg.mozilla.org/mozilla-central/rev/161c6106d787

Reopen if crashes persist.

Comment 7

[Doug Sherk (:drs) (inactive)]

I'm unable to repro this when I backout the patch. jdm: what hardware/setup are you using, and is there any other info you can give me to repro it? I'd also appreciate a more in-depth description as to how you think this should be dealt with properly.

Comment 8

[Josh Matthews [:jdm]]

I merely saw this topcrash on crash-stats, I didn't try reproducing it. I'm not certain it's worth solving properly, given that desktop e10s is on hold and mobile e10s is going away imminently on nightlies.

Comment 9

[Doug Sherk (:drs) (inactive)]

This is a problem that still has to be dealt with. It was caused by some additions I made to support blocklisting Android devices from graphics features (OpenGL Layers, WebGL, etc). Benoit wrote up a temporary fix for it, but I need to reactivate this code properly. Any info you can provide would be appreciated.

Comment 10

[Josh Matthews [:jdm]]

It looks like any content process which triggers a SetDimensions call on a webgl canvas should cause the problem. I outlined a plan to solve this properly in comment 4 - we send other bits of information to child processes already, so this would just be querying amd sending one more thing, then storing that data somewhere so that we don't need to hit the JNI for the feature status later.

Comment 11

[Doug Sherk (:drs) (inactive)]

Ok, I think I completely missed the e10s being phased out part. It sounds like based on that, there's no reason not to do these queries on a single process once this is done, i.e. the way we were already doing them minus the mistakes in handling SDK versions detailed in bug 700931.

Comment 12

[Josh Matthews [:jdm]]

Actually, it might remain necessary to solve this properly for content processes if B2G is planning to be using them, which I believe they are.

Comment 13

[Josh Matthews [:jdm]]

mwu tells me that Gonk doesn't care about this, so we can probably leave it be.

Comment 14

[Doug Sherk (:drs) (inactive)]

Ok, thanks for checking into that.

Comment 15

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

We should definitely fix this the "right way", if it's not incredibly difficult to solve generally.  Rumors of the death of multi-process Gecko are greatly exaggerated, even if particular products (desktop Firefox) aren't planning on using it in the near future.

Comment 16

[Doug Sherk (:drs) (inactive)]

Ok, I will start looking into solving it correctly then. If anyone has any repro steps or additional information on it, please provide it as right now I can't repro it.

Comment 17

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Occurs in XUL; reopening based on comment 5.

Using the Nightly XUL 2012-01-24, created a new tab and tried to go to the address while another tab was already trying to load www.cnn.com 

bp-611b0a7e-96fd-4dcd-8575-5ff982120125

Thunderbolt, 2.3

Comment 18

[Josh Matthews [:jdm]]

Comment 17 is a different crash, tracked in bug 720400.