Closed Bug 683026 Opened 12 years ago Closed 12 years ago

Crash with GL layers on Adreno 20x

Categories

(Core :: Graphics, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 619615

People

(Reporter: cjones, Unassigned)

References

Details

(Keywords: dogfood)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-fd2f3c79-2c53-498c-adb7-b1a4f2110829 .
============================================================= 

See also bp-ea4b64d3-6f96-42a8-8960-3de0d2110829.

I force-enabled GL layers in the latest nightly (8/29).  The first crash I saw was while loading Zimbra, and the second I got while loading the crash report for the first in socorro.  They looked very easy to reproduce.

The phone these were crashing on is an HTC Desire, which has an Adreno 205 GPU.  It might be that we're tickling something bad in the drivers there.
I'm not able to reproduce these crashes on a Nexus S, so this indeed seems to be a driver-related issue.

Note that we also have other reports of problems with GL layers on Adreno 205 devices (Bug 682483 and Bug 621741).
Those are likely related related, but on my phone at least I can't run fennec for more than a minute or so without crashing.  I was using force-enabled, which I believe bypasses our blacklist.  I'm 100% ok with just blacklisting the Adreno 200/205 for an initial landing.  It's middle-tier, old HW by now anyway.
Unfortunately libGLESv2_adreno200.so doesn't have any symbols so it's making this difficult to debug. 

Things to look at for this bug:
Vlad had some work around in bug 605063 for the andreno that we should investigate. As well Ali found that glTexSubImage2D crashes on the PowerVR in bug 695246 if a non default frame buffer is found that sound similar to Vlad's work around.
Summary: Crash with GL layers → Crash with GL layers on Adreno 200
Summary: Crash with GL layers on Adreno 200 → Crash with GL layers on Adreno 20x
(In reply to Benoit Girard (:BenWa) from comment #3)
> Unfortunately libGLESv2_adreno200.so doesn't have any symbols so it's making
> this difficult to debug. 
I was using the wrong param to objdump, it does have function names!

Several of the the stack addresses are off by one with the one in the report for bug 619615 Comment 22, so resolving as duplicate.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.