Closed
Bug 759225
Opened 12 years ago
Closed 12 years ago
Android devices with Tegra 2 don't support multiple current GL Contexts, hence WebGL is disabled
Categories
(Core :: Graphics: CanvasWebGL, defect)
Tracking
()
VERIFIED
FIXED
Tracking | Status | |
---|---|---|
blocking-fennec1.0 | --- | - |
People
(Reporter: callow.mark, Unassigned)
References
Details
Attachments
(1 file)
2.12 KB,
patch
|
jrmuizel
:
review-
|
Details | Diff | Splinter Review |
WebGL is disabled in Fennec 14.0a2 on my Xoom tablet running Android 4.0.3 (Ice-cream Sandwich). even with webgl.force-enabled set to true. I think this is a bug rather than a genuine blacklisting because (a) WebGL continues to not work even when webgl.force-enabled is true and (b) WebGL works in Fennec 13 on the same device, albeit slowly due to the read-back for compositing. Here is the output of about:support. Application Basics Name Fennec Version 14.0a2 User Agent Mozilla/5.0 (Android; Tablet; rv:14.0) Gecko/14.0 Firefox/14.0a2 Profile Directory Open Directory Enabled Plugins about:plugins Build Configuration about:buildconfig Crash Reports about:crashes Memory Use about:memory Extensions Name Version Enabled ID Important Modified Preferences Name Value browser.startup.homepage_override.mstone 14.0a2 extensions.lastAppVersion 14.0a2 network.cookie.prefsMigrated true webgl.force-enabled true Graphics Adapter Description Model: 'MZ604', Product: 'HUBKDDI', Manufacturer: 'Motorola', Hardware: 'stingray' Vendor ID stingray Device ID MZ604 Driver Version 15 WebGL Renderer false GPU Accelerated Windows 0. Blocked for your graphics card because of unresolved driver issues. AzureBackend skia Couldn't get device attachments for device. Couldn't get device attachments for device. Couldn't get device attachments for device. JavaScript Incremental GC 1 Library Versions Expected minimum version Version in use NSPR 4.9 4.9 NSS 3.13.4.0 Basic ECC 3.13.4.0 Basic ECC NSS Util 3.13.4.0 3.13.4.0 NSS SSL 3.13.4.0 Basic ECC 3.13.4.0 Basic ECC NSS S/MIME 3.13.4.0 Basic ECC 3.13.4.0 Basic ECC
Comment 1•12 years ago
|
||
M-C of yesterday (29 May) running on Xoom/ICS, with patch recommended over irc by bjacob: https://hg.mozilla.org/try/rev/a2f749852cae grepping for EGL in the resulting syslog produces the log below, which does contain the error 3002 that bjacob was concerned about. sewardj@u1110x64:~/MOZ/MC-29-05-2012-DROID-JEM$ grep EGL spew-tmp D/libEGL (25716): loaded /system/lib/egl/libGLES_android.so D/libEGL (25716): loaded /system/lib/egl/libEGL_tegra.so D/libEGL (25716): loaded /system/lib/egl/libGLESv1_CM_tegra.so D/libEGL (25716): loaded /system/lib/egl/libGLESv2_tegra.so I/Gecko (25716): Attempting load of libEGL.so I/Gecko (25716): Extensions: EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_fence_sync EGL_NV_system_time EGL_ANDROID_image_native_buffer EGL_ANDROID_image_native_buffer 0x45 I/Gecko (25716): CreateEGLPBufferOffscreenContext 1: aSize.width=16, aSize.height=16, red=8, green=8, blue=8, alpha=0, depth=0, stencil=0, samples=0, bufferUnused=1 I/Gecko (25716): CreateEGLPBufferOffscreenContext TRY_ATTRIBS_AGAIN attribAttempt=0 tryDepthSize=0 I/Gecko (25716): CreateEGLPBufferOffscreenContext 2 I/Gecko (25716): CreateEGLPBufferOffscreenContext 3 I/Gecko (25716): CreateEGLPBufferOffscreenContext 3 I/Gecko (25716): CreateEGLPBufferOffscreenContext 4 I/Gecko (25716): CreateEGLPBufferOffscreenContext 5 I/Gecko (25716): CreateEGLPBufferOffscreenContext 6 I/Gecko (25716): CreateEGLPBufferOffscreenContext 7 I/Gecko (25716): CreateEGLPBufferOffscreenContext 8 I/Gecko (25716): CreateEGLPBufferOffscreenContext 9 I/Gecko (25716): CreateEGLPBufferOffscreenContext 1: aSize.width=16, aSize.height=16, red=8, green=8, blue=8, alpha=8, depth=24, stencil=0, samples=4, bufferUnused=1 I/Gecko (25716): CreateEGLPBufferOffscreenContext TRY_ATTRIBS_AGAIN attribAttempt=0 tryDepthSize=24 I/Gecko (25716): CreateEGLPBufferOffscreenContext 2 I/Gecko (25716): CreateEGLPBufferOffscreenContext 3 I/Gecko (25716): CreateEGLPBufferOffscreenContext 3 I/Gecko (25716): CreateEGLPBufferOffscreenContext 4 I/Gecko (25716): CreateEGLPBufferOffscreenContext 5 I/Gecko (25716): CreateEGLPBufferOffscreenContext 6 I/Gecko (25716): CreateEGLPBufferOffscreenContext 7 E/libEGL (25716): eglMakeCurrent:674 error 3002 (EGL_BAD_ACCESS) I/Gecko (25716): CreateEGLPBufferOffscreenContext 1: aSize.width=16, aSize.height=16, red=8, green=8, blue=8, alpha=8, depth=24, stencil=0, samples=4, bufferUnused=1 I/Gecko (25716): CreateEGLPBufferOffscreenContext TRY_ATTRIBS_AGAIN attribAttempt=0 tryDepthSize=24 I/Gecko (25716): CreateEGLPBufferOffscreenContext 2 I/Gecko (25716): CreateEGLPBufferOffscreenContext 3 I/Gecko (25716): CreateEGLPBufferOffscreenContext 3 I/Gecko (25716): CreateEGLPBufferOffscreenContext 4 I/Gecko (25716): CreateEGLPBufferOffscreenContext 5 I/Gecko (25716): CreateEGLPBufferOffscreenContext 6 I/Gecko (25716): CreateEGLPBufferOffscreenContext 7 E/libEGL (25716): eglMakeCurrent:674 error 3002 (EGL_BAD_ACCESS) I/Gecko (25716): CreateEGLPBufferOffscreenContext 1: aSize.width=16, aSize.height=16, red=8, green=8, blue=8, alpha=8, depth=24, stencil=0, samples=4, bufferUnused=1 I/Gecko (25716): CreateEGLPBufferOffscreenContext TRY_ATTRIBS_AGAIN attribAttempt=0 tryDepthSize=24 I/Gecko (25716): CreateEGLPBufferOffscreenContext 2 I/Gecko (25716): CreateEGLPBufferOffscreenContext 3 I/Gecko (25716): CreateEGLPBufferOffscreenContext 3 I/Gecko (25716): CreateEGLPBufferOffscreenContext 4 I/Gecko (25716): CreateEGLPBufferOffscreenContext 5 I/Gecko (25716): CreateEGLPBufferOffscreenContext 6 I/Gecko (25716): CreateEGLPBufferOffscreenContext 7 E/libEGL (25716): eglMakeCurrent:674 error 3002 (EGL_BAD_ACCESS) I/Gecko (25716): CreateEGLPBufferOffscreenContext 1: aSize.width=16, aSize.height=16, red=8, green=8, blue=8, alpha=8, depth=24, stencil=0, samples=4, bufferUnused=1 I/Gecko (25716): CreateEGLPBufferOffscreenContext TRY_ATTRIBS_AGAIN attribAttempt=0 tryDepthSize=24 I/Gecko (25716): CreateEGLPBufferOffscreenContext 2 I/Gecko (25716): CreateEGLPBufferOffscreenContext 3 I/Gecko (25716): CreateEGLPBufferOffscreenContext 3 I/Gecko (25716): CreateEGLPBufferOffscreenContext 4 I/Gecko (25716): CreateEGLPBufferOffscreenContext 5 I/Gecko (25716): CreateEGLPBufferOffscreenContext 6 I/Gecko (25716): CreateEGLPBufferOffscreenContext 7 E/libEGL (25716): eglMakeCurrent:674 error 3002 (EGL_BAD_ACCESS) E/libEGL (25716): eglMakeCurrent:674 error 3002 (EGL_BAD_ACCESS)
Comment 2•12 years ago
|
||
Many thanks for the log. So this is the same as bug 758323. See bug 758323 comment 8 -- 14 for the explanation. This driver doesn't support having two threads with each a OpenGL context current on them, even if these are different OpenGL contexts. Unfortunately, since we switched to off-main-thread OpenGL compositing, this is a requirement for WebGL. Since the benefits of off-main-thread OpenGL compositing outweigh WebGL in the real world, this won't change, therefore there is no hope of WebGL support on this device, at least not without a OS/driver update.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Wait, whoa -- this is a big problem. The assertion in bug 758323 was that this was an issue pre-ICS only; if this is an issue in ICS as well, then I think we have deeper problems. Given how much GL gets used in ICS though, I am very surprised by this.
Comment 4•12 years ago
|
||
It is a big problem. On the bright side though, at least some Android 2.x devices are capable of two-GL-contexts-bound-on-two-different-threads, for example it works just fine on my Nexus S running Android 2.3. I don't see any solution besides multiplexing GL contexts, which would probably be inefficient and hard to get right.
Reporter | ||
Comment 5•12 years ago
|
||
It is unacceptable to close this bug as WONTFIX. By doing so you are saying you won't support WebGL on any Android ICS device with Tegra graphics. That includes a lot of very recent and upcoming devices. Discuss this problem with NVIDIA. You can contact Neil Trevett or Acorn Pooley as starting points. They're very interesting in making sure Tegra supports WebGL well and have been putting quite some effort into it. At Siggraph 2011 Neil demo'ed a version of Chrome/WebKit they'd hacked to add WebGL running WebGL Aquarium on the exact model of Xoom tablet that I have. I share Vlad's surprise. When you say "multiplexing" do you mean sharing a single context or ensuring that only one context is current at a time? The latter seems doable with a wrapper around eglMakeCurrent and a mutex. P.S. Why use pbuffers? Why not use fbos?
Comment 6•12 years ago
|
||
(In reply to Mark Callow from comment #5) > It is unacceptable to close this bug as WONTFIX. By doing so you are saying > you won't support WebGL on any Android ICS device with Tegra graphics. That > includes a lot of very recent and upcoming devices. I was just trying to be realistic here, as I don't see any way to fix this short-term, but I don't mind keeping it open just for the slim chance that things might turn out better than expected. Reopening. > > Discuss this problem with NVIDIA. You can contact Neil Trevett or Acorn > Pooley as starting points. I already emailed Antti and CC'd you earlier today. Feel free to reply-to-all and add people in CC. I didn't know Acorn and don't have his email address. > They're very interesting in making sure Tegra > supports WebGL well and have been putting quite some effort into it. At > Siggraph 2011 Neil demo'ed a version of Chrome/WebKit they'd hacked to add > WebGL running WebGL Aquarium on the exact model of Xoom tablet that I have. Chrome does separate processes as opposed to separate threads, which works around this problem. > > I share Vlad's surprise. > > When you say "multiplexing" do you mean sharing a single context or ensuring > that only one context is current at a time? I meant a single context, but of course my fear is that making it current alternatively on two contexts will cause some slow mutex locking internally in the GL implementation. > The latter seems doable with a wrapper around eglMakeCurrent and a mutex. This means that the compositor thread will sometimes find itself waiting on the main (content-rendering) thread, which is something that we wanted to never happen --- a large part of the benefits of off-main-thread-compositing is that we can keep smooth panning and scrolling under all circumstances. We lose that if we have the compositor thread lock a mutex from the main thread. > > P.S. Why use pbuffers? Why not use fbos? I lost track of our status on this (bug 720467). Joe or Jeff G would know better.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WONTFIX → ---
Comment 7•12 years ago
|
||
The most useful outcome that I can see from this bug is if it can serve to up the priority of doing one-process-per-tab Fennec. See bug 758323 comment 15 for good reasons to believe that this will successfully avoid this problem.
Comment 8•12 years ago
|
||
The only place we render to PBuffers in EGL is with ANGLE, since they are EGLSurfaces, which we can share with D3D. However, we do often create dummy PBuffers in order to create a new context for WebGL, which is the case for Android. There shouldn't be any reason we can't support only having one context current at a time, however what I remember in the past is that we've traditionally had trouble getting good performance switching between contexts on mobile. This doesn't mean we shouldn't allow this to happen, since this should be remedied somewhat by better drivers. I don't believe ditching WebGL on many(?) mobile devices is acceptable. It should work, even if it is slow for technical reasons. We should, however, reinvestigate things a bit since it seems that our newest-and-greatest architecture appears to have systemic problems resulting in poor webgl performance. The compositor should never be waiting longer on the content thread than it already waits today. The content-side glFinish we currently use should be coming out in a couple weeks anyways, hopefully. Besides, pan and zoom are not tremendously common actions with most demos.
Comment 9•12 years ago
|
||
TL;DR, we should do context-juggling even if it's slow.
Comment 10•12 years ago
|
||
(In reply to Jeff Gilbert [:jgilbert] from comment #8) > The compositor should never be waiting longer on the content thread than it > already waits today. The content-side glFinish we currently use should be > coming out in a couple weeks anyways, hopefully. Besides, pan and zoom are > not tremendously common actions with most demos. That leaves out the pages that just have a little WebGL canvas on the side but otherwise are regular Web pages. Take for example the khronos.org homepage with the spinning WebGL cube. If the compositor has to lock a mutex locked by the content thread doing WebGL work, then panning/zooming on that page will be less smooth. OTOH, I can understand the stance that it's OK as long as it's not worse than Fennec 13.
Comment 11•12 years ago
|
||
Oh, here is something that could make the mutex-locking idea actually not harm compositing performance in practice: - The content thread would lock the mutex for each WebGL call: so it would pay a high cost (WebGL would be slow) but shouldn't ever keep the mutex locked long, as WebGL calls should return fast enough. Of course it's possible to issue arbitrarily long WebGL calls, but that's the DoS issue we have anyway. - The compositor thread would only lock the mutex 60 times per second, so it would pay a much lower cost; and since the mutex should normally never be locked for too long by the other thread (see above), that mutex locking shouldn't take too long. So all in all, it seems that we should give the mutex-locking idea a good try. Have the compositor lock the mutex around compositing; have the content thread lock it around each WebGL call; have both release their own context (makeCurrent with null) before releasing the mutex. Regarding the multiplexing idea, I'm not sure it has any advantage over mutex locking, as the OpenGL implementation will probably do similar mutex locking internally.
Comment 12•12 years ago
|
||
Side note: even very slow WebGL would still be very valuable actually as our own Android test slaves, Tegra 2 dev boards, have the same issue (bug 759221 comment 5)
Updated•12 years ago
|
blocking-fennec1.0: --- → ?
Summary: WebGL disabled on Xoom tablet with ICS in Fennec 14 though it works in 13 → Android devices with Tegra 2 don't support multiple current GL Contexts, hence WebGL is disabled
We have more info; the bug is multiple contexts *in the same share group*. We automatically create contexts in a share group if sharing succeeds, though I don't know that we take advantage of any of that yet (certainly don't in WebGL, I'm pretty sure). I would suggest that we simply disable all of our sharing on Tegra 2 + Honeycomb or Xoom (HC or ICS), which is the affected set of devices. We can consider disabling it more broadly once we figure out if we can use EGLImage etc. based exporting of textures.
Comment 16•12 years ago
|
||
Indeed we have a super useful reply from NVIDIA --- currently asking for permission to paste it here.
Comment 17•12 years ago
|
||
This makes WebGL work on the Tegra! \o/ Should we land this or not? Technically, the better solution is to just return null in GLContextProviderEGL::GetGlobalContext(). But we currently rely on the existence of the global context to get the renderer string to blacklist Adreno for WebGL (bug 736123). So, getting rid of the global context altogether is slightly more tricky than anticipated, so I think we should land this for now and deal with the global context separately. Thoughts?
Comment 18•12 years ago
|
||
(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #15) > We have more info; the bug is multiple contexts *in the same share group*. > We automatically create contexts in a share group if sharing succeeds, > though I don't know that we take advantage of any of that yet (certainly > don't in WebGL, I'm pretty sure). > > I would suggest that we simply disable all of our sharing on Tegra 2 + > Honeycomb or Xoom (HC or ICS), which is the affected set of devices. We can > consider disabling it more broadly once we figure out if we can use EGLImage > etc. based exporting of textures. We use texture sharing for accel-compositing on OGL layers, and EGLSurface sharing on D3D10 layers. I don't know the state of things on android.
Comment 19•12 years ago
|
||
(In reply to Benoit Jacob [:bjacob] from comment #17) > Created attachment 628916 [details] [diff] [review] > don't join the share group > > This makes WebGL work on the Tegra! \o/ > > Should we land this or not? > > Technically, the better solution is to just return null in > GLContextProviderEGL::GetGlobalContext(). But we currently rely on the > existence of the global context to get the renderer string to blacklist > Adreno for WebGL (bug 736123). > > So, getting rid of the global context altogether is slightly more tricky > than anticipated, so I think we should land this for now and deal with the > global context separately. Thoughts? Why don't we just not try to create-as-shared on affected devices? We should already have logic in place (though probably untested) for not being in the share group. (If we don't, we should add it)
Comment 20•12 years ago
|
||
Jeff: currently, until the fast-WebGL-with-OMTC work lands, we're still reading back each WebGL frame we composite. Despite adding the WebGL context to the share group, we're currently not taking advantage of that at all. Whence my patch. My thinking was we could land it, and then the fast-WebGL-with-OMTC work would rely solely on EGLImage and not on a share group. That would leave us with a mostly-unused global context on Android. However I need to check but we should be able to get rid of the global context, actually, on Android. The reason to keep it I mentioned above, to get the GL_RENDERER string to blacklist Adreno, may not be a very good one as we might be able to detect the problem in a different way by checking the EGL error code after context creation. Will check ASAP. So we might be able to do the better, simpler approach of just disabling the global context altogether on Android. Regardless: I would really like to base the texture sharing on something (like EGLImage) that doesn't rely on share groups on Android. Do you see a downside with that? Assuming there are no downsides, we should be able to do this unconditionally on all Android devices, no?
Comment 21•12 years ago
|
||
Romaxa points out that EGLImage won't work well on all devices either, so we will likely need to maintain the two approaches and decide for which devices to use which.
Comment 22•12 years ago
|
||
We need to maintain the texture sharing path for desktop, anyways.
Comment 23•12 years ago
|
||
See comment on: https://bugzilla.mozilla.org/show_bug.cgi?id=728524#c31 EGLImage path looks very sad on androids. old and new
Comment 24•12 years ago
|
||
We're not excited about taking this for 1.0, but will take it for a dot release.
blocking-fennec1.0: ? → .N+
Comment 25•12 years ago
|
||
Comment on attachment 628916 [details] [diff] [review] don't join the share group We plan on not creating the shareContext at all on Android, which will avoid the need for this hack.
Attachment #628916 -
Flags: review-
Comment 26•12 years ago
|
||
Yep, the new patch is on bug 760675. Here is the precious information that Antti at NVIDIA gave us (and agreed to have shown on this public Bugzilla): It is an old bug from Tegra 2/Honeycomb era, and it was fixed almost a year ago. The problem is that you cannot have two contexts in the same share group on different threads. I haven't looked at your implementation, but you probably share a GL texture object (the WebGL frame) between the two contexts. It is fixed in all branches that support Tegra 3 or ICS. So, all Tegra 3 -based products and all products with ICS should have the fix, the only exception being Xoom. Moreover, there might still be some Tegra 2-based devices that shipped with Froyo, Gingerbread or Honeycomb that have this bug. The bug fix is part of the upgrade to ICS. So if OEMs offer an upgrade and users do it, they will get the fix. Fixed: - All Tegra 3 based products - All ICS products, except Xoom Potentially in risk depending on the driver version: - Tegra 2 based Froyo, Gingerbread and Honeycomb devices that haven't upgraded to ICS, and Xoom Potential workarounds: 1. Use Android's Java API SurfaceTexture to share the surface. So, create the GL contexts without sharing any objects and use SurfaceTexture to deliver frames from one context to another. This avoids the driver limitation by not sharing a GL texture object, just the underlying memory. SurfaceTexture is available on Honeycomb and Ice cream sandwich as Java API. It will take care of the synchronization for you. http://developer.android.com/reference/android/graphics/SurfaceTexture.html 2. If the Java requirement is problematic or the API is not available, you can also do this with an EGL image on native side. That's how SurfaceTexture is implemented too. It basically avoids the same problem by not needing to share any GL texture objects. In the producer, you have to create an EGL image out of the framebuffer texture, pass that over to the compositor (consumer) and create a GL texture from the EGL image. This doesn't depend on Android-specific APIs but you are responsible for synchronization. For that, you can either use glFinish or an EGL sync object, of which the latter is faster.
Comment 27•12 years ago
|
||
Now's a good time to try today's Nightly on a Tegra 2 device: WebGL should work.
Comment 28•12 years ago
|
||
Yep, fixed in today's Nightly build for me on the Tegra 2 dev board. http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2012-06-04-03-05-27-mozilla-central-android/fennec-15.0a1.multi.android-arm.apk
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
blocking-fennec1.0: .N+ → -
Comment 29•12 years ago
|
||
minused since bug 760675 has the fix
Comment 30•12 years ago
|
||
Verified also works ok for me on Xoom/ICS now.
Reporter | ||
Comment 32•12 years ago
|
||
(In reply to Benoit Jacob [:bjacob] from comment #28) > Yep, fixed in today's Nightly build for me on the Tegra 2 dev board. > > http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2012-06-04-03-05-27- > mozilla-central-android/fennec-15.0a1.multi.android-arm.apk It is not working on my Xoom/ICS. It crashes. Here are the contents of the Android log that I cleared before navigating to apps and launching "Nightly" from the above link. Note the uncaught Java exception followed by the SIGSEGV. D/OpenGLRenderer( 1557): Flushing caches (mode 1) D/dalvikvm( 723): GC_CONCURRENT freed 4002K, 30% free 12287K/17479K, paused 2ms+8ms D/dalvikvm( 723): GC_CONCURRENT freed 1238K, 27% free 12864K/17479K, paused 4ms+7ms D/dalvikvm( 723): GC_FOR_ALLOC freed 1697K, 32% free 12009K/17479K, paused 34ms D/dalvikvm( 723): GC_CONCURRENT freed 100K, 22% free 13697K/17479K, paused 3ms+7ms D/dalvikvm( 723): GC_CONCURRENT freed 2778K, 26% free 12935K/17479K, paused 2ms+6ms D/dalvikvm( 723): GC_CONCURRENT freed 657K, 19% free 14273K/17479K, paused 2ms+6ms D/dalvikvm( 723): GC_FOR_ALLOC freed 1779K, 23% free 13538K/17479K, paused 28ms D/dalvikvm( 723): GC_CONCURRENT freed 2354K, 25% free 13208K/17479K, paused 2ms+6ms I/ActivityManager( 475): START {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=org.mozilla.fennec/.App} from pid 723 D/dalvikvm( 475): GC_CONCURRENT freed 886K, 14% free 11055K/12743K, paused 3ms+8ms I/ActivityManager( 475): Start proc org.mozilla.fennec for activity org.mozilla.fennec/.App: pid=1694 uid=10011 gids={3003, 1015, 1006} D/OpenGLRenderer( 723): Flushing caches (mode 1) D/OpenGLRenderer( 723): Flushing caches (mode 0) I/ActivityThread( 1694): Pub org.mozilla.fennec.db.formhistory: org.mozilla.fennec.db.FormHistoryProvider I/ActivityThread( 1694): Pub org.mozilla.fennec.db.browser: org.mozilla.fennec.db.BrowserProvider I/ActivityThread( 1694): Pub org.mozilla.fennec.db.tabs: org.mozilla.fennec.db.TabsProvider D/GeckoProfile( 1694): Found profile dir: /data/data/org.mozilla.fennec/files/mozilla/ndec9v0v.default D/dalvikvm( 1694): Trying to load lib /data/data/org.mozilla.fennec/lib/libmozglue.so 0x410ad198 D/dalvikvm( 1694): Added shared lib /data/data/org.mozilla.fennec/lib/libmozglue.so 0x410ad198 D/dalvikvm( 1694): No JNI_OnLoad found in /data/data/org.mozilla.fennec/lib/libmozglue.so 0x410ad198, skipping init W/GeckoApp( 1694): zerdatime 355644 - onCreate D/dalvikvm( 1694): GC_CONCURRENT freed 173K, 4% free 6802K/7047K, paused 3ms+3ms D/dalvikvm( 1694): GC_CONCURRENT freed 346K, 7% free 6879K/7367K, paused 2ms+2ms I/GeckoViewsFactory( 1694): Creating custom Gecko view: FormAssistPopup I/GeckoViewsFactory( 1694): Creating custom Gecko view: AboutHomeContent I/GeckoViewsFactory( 1694): Creating custom Gecko view: FindInPageBar D/AndroidRuntime( 1694): Shutting down VM W/dalvikvm( 1694): threadid=1: thread exiting with uncaught exception (group=0x40a4b1f8) E/GeckoAppShell( 1694): >>> REPORTING UNCAUGHT EXCEPTION FROM THREAD 1 ("main") E/GeckoAppShell( 1694): java.lang.RuntimeException: Unable to start activity ComponentInfo{org.mozilla.fennec/org.mozilla.fennec.App}: java.lang.NullPointerException E/GeckoAppShell( 1694): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1978) E/GeckoAppShell( 1694): at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2003) E/GeckoAppShell( 1694): at android.app.ActivityThread.access$600(ActivityThread.java:123) E/GeckoAppShell( 1694): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1169) E/GeckoAppShell( 1694): at android.os.Handler.dispatchMessage(Handler.java:99) E/GeckoAppShell( 1694): at android.os.Looper.loop(Looper.java:137) E/GeckoAppShell( 1694): at android.app.ActivityThread.main(ActivityThread.java:4446) E/GeckoAppShell( 1694): at java.lang.reflect.Method.invokeNative(Native Method) E/GeckoAppShell( 1694): at java.lang.reflect.Method.invoke(Method.java:511) E/GeckoAppShell( 1694): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784) E/GeckoAppShell( 1694): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551) E/GeckoAppShell( 1694): at dalvik.system.NativeStart.main(Native Method) E/GeckoAppShell( 1694): Caused by: java.lang.NullPointerException E/GeckoAppShell( 1694): at org.mozilla.gecko.BrowserToolbar.from(BrowserToolbar.java:168) E/GeckoAppShell( 1694): at org.mozilla.gecko.GeckoApp.onCreate(GeckoApp.java:1795) E/GeckoAppShell( 1694): at android.app.Activity.performCreate(Activity.java:4465) E/GeckoAppShell( 1694): at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1049) E/GeckoAppShell( 1694): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1942) E/GeckoAppShell( 1694): ... 11 more F/libc ( 1694): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1) I/DEBUG ( 487): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** I/DEBUG ( 487): Build fingerprint: 'MOTO/HUBKDDI/wifi_hubble:4.0.3/I.7.1-34_KDDI-6/1335289286:user/ota-rel-keys,release-keys' I/DEBUG ( 487): pid: 1694, tid: 1694 >>> org.mozilla.fennec <<< I/DEBUG ( 487): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000 I/DEBUG ( 487): r0 016e22c0 r1 ea500019 r2 9510001d r3 00000000 I/DEBUG ( 487): r4 57024f78 r5 016e5858 r6 00000000 r7 56ca8f34 I/DEBUG ( 487): r8 beba9790 r9 56ca8f2c 10 5b37329f fp beba97a4 I/DEBUG ( 487): ip 56d4f5c9 sp beba9788 lr 56d4f5d3 pc 00000000 cpsr a0000010 I/DEBUG ( 487): d0 414000003f800000 d1 3ff0000042c80000 I/DEBUG ( 487): d2 bf80000000000000 d3 3f80000000000000 I/DEBUG ( 487): d4 3f80000000000000 d5 3ff000003f800000 I/DEBUG ( 487): d6 bff0000000000000 d7 408000003f800000 I/DEBUG ( 487): d8 0000000000000000 d9 0000000000000000 I/DEBUG ( 487): d10 0000000000000000 d11 0000000000000000 I/DEBUG ( 487): d12 0000000000000000 d13 0000000000000000 I/DEBUG ( 487): d14 0000000000000000 d15 0000000000000000 I/DEBUG ( 487): scr 60000012 I/DEBUG ( 487): I/DEBUG ( 487): #00 pc 00000000 I/DEBUG ( 487): #01 lr 56d4f5d3 /data/data/org.mozilla.fennec/lib/libmozglue.so I/DEBUG ( 487): I/DEBUG ( 487): code around pc: I/DEBUG ( 487): 00000000 ffffffff ffffffff ffffffff ffffffff ................ I/DEBUG ( 487): 00000010 ffffffff ffffffff ffffffff ffffffff ................ I/DEBUG ( 487): 00000020 ffffffff ffffffff ffffffff ffffffff ................ I/DEBUG ( 487): 00000030 ffffffff ffffffff ffffffff ffffffff ................ I/DEBUG ( 487): 00000040 ffffffff ffffffff ffffffff ffffffff ................ I/DEBUG ( 487): I/DEBUG ( 487): code around lr: I/DEBUG ( 487): 56d4f5b0 bd104798 00010890 b5104b02 681b447b .G.......K..{D.h I/DEBUG ( 487): 56d4f5c0 bd104798 000108e4 b5104b02 681b447b .G.......K..{D.h I/DEBUG ( 487): 56d4f5d0 bd104798 0001089c b5104b02 681b447b .G.......K..{D.h I/DEBUG ( 487): 56d4f5e0 bd104798 0001089c b5104b02 681b447b .G.......K..{D.h I/DEBUG ( 487): 56d4f5f0 bd104798 000108dc b085b530 4020f89d .G......0..... @ I/DEBUG ( 487): I/DEBUG ( 487): stack: I/DEBUG ( 487): beba9748 4081ed80 /system/lib/libdvm.so I/DEBUG ( 487): beba974c 400f4498 I/DEBUG ( 487): beba9750 40beca08 /dev/ashmem/dalvik-heap (deleted) I/DEBUG ( 487): beba9754 beba9798 [stack] I/DEBUG ( 487): beba9758 016e9fe8 [heap] I/DEBUG ( 487): beba975c beba9798 [stack] I/DEBUG ( 487): beba9760 b5c9e822 I/DEBUG ( 487): beba9764 40850bab /system/lib/libdvm.so I/DEBUG ( 487): beba9768 01839b00 [heap] I/DEBUG ( 487): beba976c 400f44b8 I/DEBUG ( 487): beba9770 00000020 I/DEBUG ( 487): beba9774 400f4474 I/DEBUG ( 487): beba9778 4111d6b8 /dev/ashmem/dalvik-heap (deleted) I/DEBUG ( 487): beba977c 4111d6b8 /dev/ashmem/dalvik-heap (deleted) I/DEBUG ( 487): beba9780 016e5858 [heap] I/DEBUG ( 487): beba9784 016e5900 [heap] I/DEBUG ( 487): #00 beba9788 57024f78 /dev/ashmem/dalvik-LinearAlloc (deleted) I/DEBUG ( 487): beba978c 4081ebf4 /system/lib/libdvm.so I/DEBUG ( 487): beba9790 56ca8f2c I/DEBUG ( 487): beba9794 00000001 I/DEBUG ( 487): beba9798 410fc708 /dev/ashmem/dalvik-heap (deleted) I/DEBUG ( 487): beba979c 016e5868 [heap] I/DEBUG ( 487): beba97a0 beba9a10 [stack] I/DEBUG ( 487): beba97a4 40859339 /system/lib/libdvm.so I/DEBUG ( 487): beba97a8 56ca8f2c I/DEBUG ( 487): beba97ac 5b37329d /data/dalvik-cache/data@app@org.mozilla.fennec-2.apk@classes.dex I/DEBUG ( 487): beba97b0 56d4f5c9 /data/data/org.mozilla.fennec/lib/libmozglue.so I/DEBUG ( 487): beba97b4 016e5868 [heap] I/DEBUG ( 487): beba97b8 00000000 I/DEBUG ( 487): beba97bc 00000000 I/DEBUG ( 487): beba97c0 00000000 I/DEBUG ( 487): beba97c4 ea500019 I/DEBUG ( 487): beba97c8 400f44e0 I/DEBUG ( 487): beba97cc 400f44e0 I/BootReceiver( 475): Copying /data/tombstones/tombstone_06 to DropBox (SYSTEM_TOMBSTONE) D/Zygote ( 422): Process 1694 terminated by signal (11) D/dalvikvm( 475): GC_FOR_ALLOC freed 503K, 10% free 11538K/12743K, paused 54ms I/ActivityManager( 475): Process org.mozilla.fennec (pid 1694) has died. W/ActivityManager( 475): Force removing ActivityRecord{41345740 org.mozilla.fennec/.App}: app died, no saved state W/InputManagerService( 475): Window already focused, ignoring focus gain of: com.android.internal.view.IInputMethodClient$Stub$Proxy@4150c5a0 D/dalvikvm( 723): GC_FOR_ALLOC freed 2792K, 31% free 12163K/17479K, paused 32ms D/dalvikvm( 723): GC_CONCURRENT freed 313K, 22% free 13725K/17479K, paused 3ms+10ms D/dalvikvm( 723): GC_CONCURRENT freed 2680K, 26% free 13021K/17479K, paused 2ms+6ms D/OpenGLRenderer( 723): Flushing caches (mode 1) D/dalvikvm( 552): GC_CONCURRENT freed 252K, 60% free 7891K/19271K, paused 6ms+5ms D/OpenGLRenderer( 723): Flushing caches (mode 0) D/OpenGLRenderer( 552): Flushing caches (mode 0) W/InputManagerService( 475): Starting input on non-focused client com.android.internal.view.IInputMethodClient$Stub$Proxy@4146ca98 (uid=10027 pid=723) D/dalvikvm( 1557): GC_CONCURRENT freed 4147K, 45% free 6877K/12359K, paused 6ms+3ms
Comment 33•12 years ago
|
||
Thanks Mark for the report. This seems like a separate bug that I didn't know about. Could you please go to about:crashes and paste your crash link here? Then we'll see if we should reopen or continue in a separate bug.
Reporter | ||
Comment 34•12 years ago
|
||
If you mean go to about:crashes in the browser that is crashing, I can't. It crashes before I have any opportunity to enter anything in the Awesome bar.
Comment 35•12 years ago
|
||
Oh! So the crash has nothing to do with WebGL? Then please do file a separate bug for this. Startup crashes are the most important to fix!
Reporter | ||
Comment 36•12 years ago
|
||
What product & component should I use for the bug report?
Reporter | ||
Comment 37•12 years ago
|
||
I filed bug #761505 under Fennec/General. Please change it to appropriate product and component.
Reporter | ||
Comment 38•12 years ago
|
||
OK. The crash has been fixed. This version is using the non-shared context so a read-back is still required, right? I hope you can get the EGLImage version working so you can avoid the read-back as performance with it on a tablet-sized device is too slow to be truly usable.
Comment 39•12 years ago
|
||
Correct. The work to use EGLImage to avoid the read-back is being done in bug 728524.
You need to log in
before you can comment on or make changes to this bug.
Description
•