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)

Product:
Core
Component:
Graphics: CanvasWebGL
Version:
14 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Tracking Flags:
Tracking Status
blocking-fennec1.0 --- -

People

(Reporter: callow.mark, Unassigned)

References

Details

Attachments

(1 file)

don't join the share group
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
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)
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.
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.
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?
(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 → ---
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.
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.
TL;DR, we should do context-juggling even if it's slow.
(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.
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.
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)
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.
Indeed we have a super useful reply from NVIDIA --- currently asking for permission to paste it here.
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?
(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.
(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)
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?
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.
We need to maintain the texture sharing path for desktop, anyways.
See comment on:
https://bugzilla.mozilla.org/show_bug.cgi?id=728524#c31
EGLImage path looks very sad on androids. old and new
We're not excited about taking this for 1.0, but will take it for a dot release.
blocking-fennec1.0: ? → .N+
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-
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.
Now's a good time to try today's Nightly on a Tegra 2 device: WebGL should work.
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
blocking-fennec1.0: .N+ → -
minused since bug 760675 has the fix
Verified also works ok for me on Xoom/ICS now.
Then it's VERIFIED. Thanks!
Status: RESOLVED → VERIFIED
(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
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.
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.
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!
What product & component should I use for the bug report?
I filed bug #761505 under Fennec/General. Please change it to appropriate product and component.
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.
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.

Attachment

General

Creator:
Created:
Updated:
Size: