It first appeared in 14.0a1/20120315.
Signature AndroidGLController::ProvideEGLSurface More Reports Search
Date Processed 2012-04-01 03:33:37
Last Crash 26 seconds before submission
Install Age 38 seconds since version was first installed.
Install Time 2012-04-01 03:32:46
Build ID 20120331161857
Release Channel nightly
OS Version 0.0.0 Linux 126.96.36.199-perf #1 PREEMPT Tue Aug 9 21:02:37 2011 armv7l
Build Architecture arm
Build Architecture Info
Crash Reason SIGSEGV
Crash Address 0x8
EGL? EGL+ AdapterVendorID: semc, AdapterDeviceID: R800at.
AdapterDescription: 'Android, Model: 'R800at', Product: 'R800at_1248-6414', Manufacturer: 'Sony Ericsson', Hardware: 'semc''.
Sony Ericsson R800at
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:
There is a spike in startup crashes from 14.0a1/20120331031108. The regression range for the spike is:
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
* Sony Ericsson R800at
Err... how glx test for GLX drivers caused problem with android EGL stuff?
(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.
Other possible culprits are bug 739488 and bug 740190.
(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?
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.
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)
No crash should occur after step 3
Firefox 14.0a1 (2012-04-01)
Devices: HTC Desire (2.2), Motorola Droid 2 (2.3.3), Samsung Nexus (4.0.2)
Here is a video about this crash: http://youtu.be/lMMry-SA_S4
Created attachment 611489 [details] [diff] [review]
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.
Comment on attachment 611489 [details] [diff] [review]
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? ;-)
And in response to KaiRo's suggestion: https://hg.mozilla.org/integration/mozilla-inbound/rev/7da9ecd5424f
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
The build from April 3rd (http://hg.mozilla.org/mozilla-central/rev/95df15895e02) doesn't contain the fix.
Verified fixed on:
Firefox 14.0a1 (2012-04-04)
Device: Samsung Galaxy S
OS: Android 2.2
*** Bug 686457 has been marked as a duplicate of this bug. ***