Note: There are a few cases of duplicates in user autocompletion which are being worked on.

crash in AndroidGLController::ProvideEGLSurface

VERIFIED FIXED in mozilla14

Status

()

Core
Widget: Android
--
critical
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: Scoobidiver (away), Assigned: Joe Drew (not getting mail))

Tracking

(4 keywords)

14 Branch
mozilla14
ARM
Android
crash, regression, reproducible, topcrash
Points:
---

Firefox Tracking Flags

(blocking-fennec1.0 +)

Details

(Whiteboard: [native-crash][startupcrash], crash signature)

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
It first appeared in 14.0a1/20120315.

Signature 	AndroidGLController::ProvideEGLSurface More Reports Search
UUID	00c6f9c3-7173-467e-abd0-269962120401
Date Processed	2012-04-01 03:33:37
Uptime	4
Last Crash	26 seconds before submission
Install Age	38 seconds since version was first installed.
Install Time	2012-04-01 03:32:46
Product	FennecAndroid
Version	14.0a1
Build ID	20120331161857
Release Channel	nightly
OS	Linux
OS Version	0.0.0 Linux 2.6.32.9-perf #1 PREEMPT Tue Aug 9 21:02:37 2011 armv7l
Build Architecture	arm
Build Architecture Info	
Crash Reason	SIGSEGV
Crash Address	0x8
App Notes 	
EGL? EGL+ AdapterVendorID: semc, AdapterDeviceID: R800at.
AdapterDescription: 'Android, Model: 'R800at', Product: 'R800at_1248-6414', Manufacturer: 'Sony Ericsson', Hardware: 'semc''.
Sony Ericsson R800at
AT&T/R800at_1248-6414/R800at:2.3.3/3.0.1.B.0.270/8W7P:user/release-keys
EMCheckCompatibility	True

Frame 	Module 	Signature 	Source
0 	libdvm.so 	libdvm.so@0x43262 	
1 	libxul.so 	AndroidGLController::ProvideEGLSurface 	jni.h:706
2 	libxul.so 	mozilla::AndroidBridge::ProvideEGLSurface 	widget/android/AndroidBridge.cpp:1115
3 	libxul.so 	mozilla::gl::GLContextProviderEGL::CreateForWindow 	gfx/gl/GLContextProviderEGL.cpp:1507
4 	libxul.so 	mozilla::layers::LayerManagerOGL::CreateContext 	gfx/layers/opengl/LayerManagerOGL.cpp:172
5 	libxul.so 	mozilla::layers::CompositorParent::AllocPLayers 	LayerManagerOGL.h:110
6 	libxul.so 	mozilla::layers::PCompositorParent::OnMessageReceived 	obj-firefox/ipc/ipdl/PCompositorParent.cpp:470
7 	libxul.so 	mozilla::ipc::SyncChannel::OnDispatchMessage 	ipc/glue/SyncChannel.cpp:175
8 	libxul.so 	mozilla::ipc::RPCChannel::OnMaybeDequeueOne 	ipc/glue/RPCChannel.cpp:432
9 	libxul.so 	RunnableMethod<mozilla::ipc::RPCChannel, bool , Tuple0>::Run 	ipc/chromium/src/base/tuple.h:383
10 	libxul.so 	mozilla::ipc::RPCChannel::DequeueTask::Run 	RPCChannel.h:462
11 	libxul.so 	MessageLoop::RunTask 	ipc/chromium/src/base/message_loop.cc:318
12 	libxul.so 	MessageLoop::DeferOrRunPendingTask 	ipc/chromium/src/base/message_loop.cc:326
13 	libxul.so 	MessageLoop::DoWork 	ipc/chromium/src/base/message_loop.cc:426
14 	libxul.so 	base::MessagePumpDefault::Run 	ipc/chromium/src/base/message_pump_default.cc:23
15 	libxul.so 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:208
16 	libxul.so 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:201
17 	libxul.so 	base::Thread::ThreadMain 	ipc/chromium/src/base/thread.cc:156
18 	libxul.so 	ThreadFunc 	ipc/chromium/src/base/platform_thread_posix.cc:26
19 	libc.so 	libc.so@0x119a6 	
20 	libc.so 	libc.so@0x11572 	

More reports at:
https://crash-stats.mozilla.com/report/list?signature=AndroidGLController%3A%3AProvideEGLSurface
(Reporter)

Comment 1

5 years ago
There is a spike in startup crashes from 14.0a1/20120331031108. The regression range for the spike is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=92fe907ddac8&tochange=4c43cfe73516
It's likely a regression from bug 740244.

Crashes after the spike occur on:
* LGE LG-P925, LG-P990
* NEC N-01D
* Samsung Galaxy Nexus, Nexus S, SCH-I500
* SMDKV210
* Sony Ericsson R800at
Blocks: 740244
Crash Signature: [@ AndroidGLController::ProvideEGLSurface] → [@ AndroidGLController::ProvideEGLSurface] [@ dalvik-LinearAlloc (deleted)@0x2376de] [@ dalvik-LinearAlloc (deleted)@0x23a20e] [@ dalvik-LinearAlloc (deleted)@0x23b6ee]
Whiteboard: [native-crash] → [native-crash][startupcrash]
Err... how glx test for GLX drivers caused problem with android EGL stuff?
(Reporter)

Comment 3

5 years ago
(In reply to Oleg Romashin (:romaxa) from comment #2)
> Err... how glx test for GLX drivers caused problem with android EGL stuff?
Wrong bug because of EGL in its title.
It might a regression from bug 737437.
Blocks: 737437
No longer blocks: 740244
Crash Signature: [@ AndroidGLController::ProvideEGLSurface] [@ dalvik-LinearAlloc (deleted)@0x2376de] [@ dalvik-LinearAlloc (deleted)@0x23a20e] [@ dalvik-LinearAlloc (deleted)@0x23b6ee] → [@ AndroidGLController::ProvideEGLSurface] [@ dalvik-LinearAlloc (deleted)@0x2376de] [@ dalvik-LinearAlloc (deleted)@0x2378fe] [@ dalvik-LinearAlloc (deleted)@0x238876] [@ dalvik-LinearAlloc (deleted)@0x23a20e] [@ dalvik-LinearAlloc (deleted)@&hellip;
(Reporter)

Comment 4

5 years ago
Other possible culprits are bug 739488 and bug 740190.

Comment 5

5 years ago
(In reply to Scoobidiver from comment #3)
> It might a regression from bug 737437.

The patch for Bug 737437 that's in the regression range was also backed out within the regression range. The latest patch for Bug 737437 only made it to mozilla-central last night, so it's not in 14.0a1/20120331031108.

Since this crash is happening during the call to AndroidBridge::ProvideEGLSurface that happens right after AndroidBridge::RegisterCompositor, one plausible theory is that the call to GetJNIForThread in RegisterCompositor is failing, causing RegisterCompositor to return early without calling sController.Acquire, leading to a crash during the call to sController.ProvideEGLSurface.

kats, is it likely/possible that the call to GetJNIForThread is failing?
No longer blocks: 737437
It's possible that GetJNIForThread is failing, but I wouldn't consider it likely. I don't think I've ever seen that fail before, but I don't know the specifics of how dalvik finds a JNIEnv for a random pthread.
(Reporter)

Updated

5 years ago
blocking-fennec1.0: --- → ?
Crash Signature: [@ AndroidGLController::ProvideEGLSurface] [@ dalvik-LinearAlloc (deleted)@0x2376de] [@ dalvik-LinearAlloc (deleted)@0x2378fe] [@ dalvik-LinearAlloc (deleted)@0x238876] [@ dalvik-LinearAlloc (deleted)@0x23a20e] [@ dalvik-LinearAlloc (deleted)@&hellip; → [@ AndroidGLController::ProvideEGLSurface] [@ JNI_GetCreatedJavaVMs] [@ dalvik-LinearAlloc (deleted)@0x2376de] [@ dalvik-LinearAlloc (deleted)@0x2378fe] [@ dalvik-LinearAlloc (deleted)@0x2380be] [@ dalvik-LinearAlloc (deleted)@0x238f5e] [@ da&hellip;
Keywords: topcrash
This crash still occurs on the latest Nightly build:

Steps to reproduce:
1. Open Fennec
2. Right after performing step 1, tap on URL Bar
3. Tap on Bookmarks tab and then on History tab (keep switching them quickly until the crash will occur)

Expected result:
No crash should occur after step 3

Actual result:
https://crash-stats.mozilla.com/report/index/b5786873-7b9b-4948-bcdd-55cb12120402

--
Firefox 14.0a1 (2012-04-01)
Devices: HTC Desire (2.2), Motorola Droid 2 (2.3.3), Samsung Nexus (4.0.2)
(Reporter)

Updated

5 years ago
Keywords: reproducible
Here is a video about this crash: http://youtu.be/lMMry-SA_S4
(Assignee)

Comment 9

5 years ago
Created attachment 611489 [details] [diff] [review]
restore waitForValidSurface

Ali tells me that, before we call egl functions on our window, we have to wait for a valid EGL surface. I removed this code in bug 737949 because I didn't think it was necessary any more, but this is apparently an Android requirement.

I can't reproduce the crash mentioned in comment 7 with this fix.
Assignee: nobody → joe
Attachment #611489 - Flags: review?(ajuma)
(Reporter)

Updated

5 years ago
Blocks: 737949

Updated

5 years ago
Attachment #611489 - Flags: review?(ajuma) → review+

Comment 10

5 years ago
Comment on attachment 611489 [details] [diff] [review]
restore waitForValidSurface

I'm not a reviewer or such, but shouldn't some comment(s) be added to make clear why this is needed? I mean, if you thought it could be removed yourself before being bitten by this, anyone else could run into the same wrong thought and should be warned when looking into the code, right? ;-)
(Assignee)

Comment 11

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/3c1d6080a98f
(Assignee)

Comment 12

5 years ago
And in response to KaiRo's suggestion: https://hg.mozilla.org/integration/mozilla-inbound/rev/7da9ecd5424f
https://hg.mozilla.org/mozilla-central/rev/3c1d6080a98f
https://hg.mozilla.org/mozilla-central/rev/7da9ecd5424f
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla14
I am still able to reproduce this issue by performing the steps from comment #7 or by tapping continuous in URL Bar just after Fennec is opened. Reopening bug

--
Firefox 14.0a1 (2012-04-03)
Device: HTC Desire Z
OS: Android 2.3.3
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Reporter)

Comment 15

5 years ago
The build from April 3rd (http://hg.mozilla.org/mozilla-central/rev/95df15895e02) doesn't contain the fix.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
Verified fixed on:

Firefox 14.0a1 (2012-04-04)
Device: Samsung Galaxy S
OS: Android 2.2
Status: RESOLVED → VERIFIED

Updated

5 years ago
Duplicate of this bug: 686457
blocking-fennec1.0: ? → +
(Reporter)

Updated

5 years ago
Crash Signature: [@ AndroidGLController::ProvideEGLSurface] [@ JNI_GetCreatedJavaVMs] [@ dalvik-LinearAlloc (deleted)@0x2376de] [@ dalvik-LinearAlloc (deleted)@0x2378fe] [@ dalvik-LinearAlloc (deleted)@0x2380be] [@ dalvik-LinearAlloc (deleted)@0x238f5e] [@ da&hellip; → [@ AndroidGLController::ProvideEGLSurface] [@ JNI_GetCreatedJavaVMs] [@ JNI_GetCreatedJavaVMs | AndroidGLController::ProvideEGLSurface] [@ dalvik-LinearAlloc (deleted)@0x2376de] [@ dalvik-LinearAlloc (deleted)@0x2378fe] [@ dalvik-LinearAlloc (&hellip;
You need to log in before you can comment on or make changes to this bug.