Closed Bug 721383 Opened 8 years ago Closed 7 years ago

Hang/crash/os reboot focusing, then blurring

Categories

(Firefox for Android :: General, defect, P1, critical)

ARM
Android
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox11 - ---
firefox12 - affected
firefox13 - affected

People

(Reporter: martijn.martijn, Unassigned)

References

()

Details

(4 keywords, Whiteboard: [native-crash])

Attachments

(3 files)

Attached file testcase
See testcase, this focus and blurs a contenteditable element, which causes the vkb to appear and disappear.
On my LG Optimus Black, Android 2.2.2, this causes the whole phone to hang, after a while.

This might be related to bug 711046, I don't know.
I'm also seeing the corruption for which I filed bug 720125.


I haven't seen this problem on the Asus EeeTransformer TF101.
This is a log from logcat until right at the point where I try to tap on the "Force Close" button of the os dialog that comes up after a while, because Fennec doesn't respond. The dialog didn't disappear in this case, though. It faded a little and then the whole os seemed stuck.
Here is a video of the hang: http://www.youtube.com/watch?v=yFdVys_Be8A
This was with almost the exact testcase (I had to manually tap outside the contenteditable div to make the vkb disappear).

Note that I could just as easily reproduce this without any scripting at all. Just by repeatedly tapping inside the contenteditable div and then outside it, I could reproduce this hang.
Keywords: testcase
Whiteboard: [native-crash]
something is really wrong with the LG Optimus Black.  I suspect OGL driver issues.  We should blacklist it from the Android store until we figure it out.
Ok, this is a recent regression:
2012-01-19 03-11-05 stable
2012-01-20 03-11-25 crash/hang
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2012-01-19+03%3A11%3A05&enddate=2012-01-20+03%3A11%3A25
Regression from bug 716415?
Keywords: regression
(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #4)
> http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2012-01-
> 19+03%3A11%3A05&enddate=2012-01-20+03%3A11%3A25
It's larger than that (the build starts 3 hours before it's built):
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=58e933465c36&tochange=5c2bc94d359c
(In reply to Doug Turner (:dougt) from comment #3)
> something is really wrong with the LG Optimus Black.  I suspect OGL driver
> issues.  We should blacklist it from the Android store until we figure it
> out.

This is a regression, before this issue, the LG Optimus Black was reasonably useful.
Blocks: 720125
Matt Woodrow, can you reproduce this?
I don't have an Optimus Black device to test this with.

This seems unlikely to be related to bug 716415, since skia is only used for plugins.

James: Is there any skia interaction involved when bringing up the vkb?
(In reply to Matt Woodrow (:mattwoodrow) from comment #8)
> James: Is there any skia interaction involved when bringing up the vkb?

Negative. I agree that this is unlikely to have anything to do with Skia.

Is this still able to be reproduced on the latest nightly? Are you doing anything silly like forcing gralloc to be used?
Yes, it can still be reproduce on the latest nightly. In about:config I have
direct-texture.force.enabled=false
I've even tried direct-texture.force.disabled=true, to see if that would fix the hangs/crashes, but that didn't help at all.
I did some hg bisecting
http://hg.mozilla.org/mozilla-central/rev/6012abe637a8
gave me a build that didn't show the bug

http://hg.mozilla.org/mozilla-central/rev/0dda5c0d994f
gave me a build that did show the bug

I tried bisecting inbetween, but then I got a build that crashed almost immediately after starting.

Could this be a regression from bug 719429 somehow?
Sorry, comment 11 appears to be wrong, I did some more bisecting.
I did:
hg bisect -g 58e933465c36
hg bisect -b 55168447493a
hg identify returns me then 7e7800f6e68b which also shows the bug.
So I did hg bisect -b 7e7800f6e68b
Then hg identify gives me 19a5e75b8ed8
Why???
That changeset is later than 7e7800f6e68b so of course that one shows the bug then too.

Or is pushloghtml upside down?
58e933465c36 is good
55168447493a is bad
7e7800f6e68b is bad
51dcdc85081c is bad
14ec9677313b is bad
f76b576a9e28 is crashing almost immediately after start, so unable to test.

What does that mean?
Filling this in pushloghtml (is there an easier way than to do have to muck within the url bar?), I get this:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=58e933465c36&tochange=14ec9677313b
There are still >100 changesets in there :(
Because f76b576a9e28 is crashing, I did:
hg bisect -s f76b576a9e28
I get:
changeset:   84841:f76b576a9e28
parent:      84791:58e933465c36
parent:      84840:cfd3838b4dc2
user:        Marco Bonardo <mbonardo@mozilla.com>
date:        Thu Jan 19 11:34:17 2012 +0100
summary:     Merge last green PGO from inbound to central

changeset:   84883:14ec9677313b
parent:      84882:d0db3841139c
parent:      84841:f76b576a9e28
user:        Marco Bonardo <mbonardo@mozilla.com>
date:        Thu Jan 19 11:36:52 2012 +0100
summary:     Merge central to inbound

How can I narrow this down further?
Sorry, forgot to add this (which is before the mentioned changesets:
Due to skipped revisions, the first bad revision could be any of:
Now I did hg bisect -e and then I got changeset 7538f4d4697c
7538f4d4697c is crashing directly after load again.

mbrubeck said on irc I could use as an alternative hg up -c <changeset>
622f1d1e7c52 is bad
2cfe51d20cce is bad
eea95e86541f is bad
79b026da30f0 is bad
aba1658ce66c is bad
78f821cb8974 crashes on startup
96a9dffede07 crashes on startup
1024e7260173 crashes on startup
I think the startup crash temporary issue hides the reboot issue.
Ok, it turns out that not building with debug enabled fixes the crash on startup.
That allowed me to bisect further.


The first bad revision is:
changeset:   84851:aba1658ce66c
parent:      84840:cfd3838b4dc2
user:        James Willcox <jwillcox@mozilla.com>
date:        Wed Jan 18 20:41:28 2012 -0500
summary:     Bug 719233 - Only use direct texturing on whitelisted devices r=blassey

So this changeset seems to be the cause of this bug.
I verified this by testing without and with this changeset.

What I find strange is that in about:config I set direct-texture.force.disabled=true (restarted afterwards), I still get this bug.
This is a catlog of fennec, just after aba1658ce66c went in and with texture.force.disabled=true in about:config, hence this in the log:
02-04 19:21:58.972: I/AndroidGraphicBuffer(2657): disallowing board 'lgp970' due to prefs override
The patch from bug 719233 was also checked in on Firefox 11 beta now :(

This makes Fennec totally unusable on the LG Optimus Black. The testcase in this bug makes it really easy to reproduce (within secondes, making it easy to find the regression range), but I see these hangs/crashes happening all of the time.
I checked the Droid X on DA, using a nightly build. It has the same GPU as the LG Optimus Black, PowerVR SGX530 and the same chipset. But I don't see this problem occuring on that phone.
tracking-fennec: --- → ?
Priority: -- → P1
tracking-fennec: ? → ---
I sent this LG Optimus Black phone to the Mountain View office (to Anthony Chung).
So hopefully someone can find out what's going wrong here.
tony, can I get that device?
Duplicate of this bug: 720125
(In reply to Doug Turner (:dougt) from comment #25)
> tony, can I get that device?

Doug, Sorry for the delayed response.  the device arrive last week, and it's with Naoki at the moment.  let me know when you want it.
OS: Android → MeeGo
Target Milestone: --- → Firefox 13
Version: Trunk → Firefox 14
OS: MeeGo → Android
Target Milestone: Firefox 13 → ---
Version: Firefox 14 → Trunk
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.