Closed Bug 752153 Opened 8 years ago Closed 8 years ago

Unable to open any web page on HTC One X/ICS

Categories

(Firefox for Android :: General, defect, blocker)

15 Branch
ARM
Android
defect
Not set
blocker

Tracking

()

VERIFIED FIXED
Firefox 15
Tracking Status
firefox14 --- fixed
firefox15 --- verified
blocking-fennec1.0 --- beta+

People

(Reporter: nrc, Assigned: snorp)

References

Details

(Keywords: regression, relnote)

Attachments

(4 files)

Attached file log
Open Nightly on HTC One X, can display the opening page, but clicking any of the links or entering an address doesn't change the display (continues to render the opening page), displays a 'thinking' 'favicon', but never completes.

Tried this with today's (5/5/12 NZ) nightly downloaded from the website and with a debug build of moz-central (http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-central-android-debug/1336182578/). The last nightly I ran was from Monday, with no problems, also tried a debug build from Try from 3/5/12 (but the pull might have been 2/5/12), also no problems.

Logs attached are from the above debug version, I opened FF twice and tried to follow a link and then use the address bar and then quit (in each case). Logs are filtered for tag=gecko.*, let me know if you want more.
This sounds exactly like bug 751732; possible shader compilation failure?  This is a huge problem.
Severity: normal → blocker
blocking-fennec1.0: --- → ?
Hardware: x86_64 → ARM
I have logs run with MOZ_GL_DEBUG=1, log_aurora is for the current aurora release (14.0.2, I think, presumably an optimised build), works fine, log_nightly, is for the debug build of moz-central, build 1336182578, broken. In both cases I load the browser and try to go to the Firefox support page via the link on the home screen, then quit. With the nightly there is a whole bunch of warnings and it doesn't seem to try to initialize OpenGL - no confirms or errors/warnings. Therefore feels like its not a shader compilation problem. Could it be a problem from the reorganising of the libraries (moving stuff from libxul to gkmedias)?
Nick, can you give us the MOZ_GL_DEBUG trace, i.e., follow the instructions at https://bugzilla.mozilla.org/show_bug.cgi?id=751732#c15 ?
Also, which version of the HTC One X do you have, Nick? Does it have a Tegra 3 or a Qualcomm CPU?
(In reply to Joe Drew (:JOEDREW!) from comment #5)
> Nick, can you give us the MOZ_GL_DEBUG trace, i.e., follow the instructions
> at https://bugzilla.mozilla.org/show_bug.cgi?id=751732#c15 ?

I tried to do this for the second two logs attached, but for the buggy nightly there was no GL output (I tried it a few times), it's possible I just got it wrong, but the Aurora version (which worked) did output GL stuff, so I think I did it right (although it is not a debug version, so maybe that isn't the GL debug log you're after).

The phone is the quad-core Tegra 3 version.
I think that means it was the mega-changeset when the tree was reopened: https://tbpl.mozilla.org/?rev=9ebf3dc839c5 but I'm not 100% sure about matching the builds to the tree pushes.
(In reply to Nick Cameron [:nrc] from comment #9)
> I think that means it was the mega-changeset when the tree was reopened:
> https://tbpl.mozilla.org/?rev=9ebf3dc839c5 but I'm not 100% sure about
> matching the builds to the tree pushes.

Looking through that (massive) list, Bug 730890 looks like something that might be able to cause a hang. If this theory is correct, this one should work:
http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-inbound-android/1336075009/fennec-15.0a1.en-US.android-arm.apk

and this one should be broken:
http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-inbound-android/1336078488/fennec-15.0a1.en-US.android-arm.apk

(This would actually narrow the regression range to https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7cd83841136c&tochange=7315f04e0303 but we can't narrow it any further using inbound builds because of intermediate bustage.)
Bug 730890 has not been uplifted to aurora.  Has anyone seen this on Aurora?
(In reply to JP Rosevear [:jpr] from comment #12)
> Bug 730890 has not been uplifted to aurora.  Has anyone seen this on Aurora?

Aurora works fine on for me.

I'll try the above inbound builds today.
(In reply to Ali Juma [:ajuma] from comment #11)
> Looking through that (massive) list, Bug 730890 looks like something that
> might be able to cause a hang. If this theory is correct, this one should
> work:
> http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-
> inbound-android/1336075009/fennec-15.0a1.en-US.android-arm.apk
> 
> and this one should be broken:
> http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-
> inbound-android/1336078488/fennec-15.0a1.en-US.android-arm.apk

Confirmed - the first build works, the second is broken.
Blocks: 730890
Joe, can you fire up some try builds to ensure bug 730890 is indeed the culprit? (Or just a general bisection).  I think Andreas' patches are off by default though.
Confirmed on my phone that it's definitely the patch in bug 730890 causing this.
eflores has the same model HTC One X as me, he patched a working source tree with the 730890 patch only and got the same bustage as we got with the current nightly.
Excellent, thanks for digging in here.  Carrying beta+ forward from soon to be dupe bug 751732
Assignee: nobody → snorp
blocking-fennec1.0: ? → +
Duplicate of this bug: 751732
blocking-fennec1.0: + → beta+
This might not be the same problem as 751732 - that bug gets a shader compilation error, whereas here we don't seem to even try to compile the shaders, also, if I understand their report properly, they get an actual crash, whereas here FF stays entirely responsive and non-crashy, it just doesn't display any web pages.
blocking-fennec1.0: beta+ → ---
Nominating for blocker.  Also adding relnote keyword just in case this bug isn't fixed in beta; we can block the HTC One X in the Google Play Store if needed.
blocking-fennec1.0: --- → ?
Keywords: regression, relnote
Whether shaders fail to compile can depend on the device/drivers.
blocking-fennec1.0: ? → beta+
This is very strange. Are there any other known devices with this issue? The patch for bug 730890 should not be device dependent at all.
Aaron, can you try the builds in #11 on Device Anywhere?
Keywords: qawanted
I beta+'ed this to carry forward from the other bug, but if these errors aren't being seen on any of the devices on Aurora, then it may not beta+ us.
Yury, you may also want to test the builds in #11.
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #23)
> This is very strange. Are there any other known devices with this issue? The
> patch for bug 730890 should not be device dependent at all.

See the duped bug.
(In reply to JP Rosevear [:jpr] from comment #26)
> Yury, you may also want to test the builds in #11.

The two builds specified in the comment #11 work.
(In reply to JP Rosevear [:jpr] from comment #27)
> (In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #23)
> > This is very strange. Are there any other known devices with this issue? The
> > patch for bug 730890 should not be device dependent at all.
> 
> See the duped bug.

Do you mean 751732? I don't agree that that is a duplicate of this one. In bug 751732 you can clearly see we fail to create a GL context. There is no such message in this bug.
I can reproduce this on a Tegra 3 HTC One X we have in the Toronto office. In this case, it looks as though Gecko is never starting up.

Interestingly, I *can't* reproduce this in my debug-only, no optimize, build. I'm doing an optimized build now to see if that changes anything.
We can reproduce this with debug builds, both downloaded from tbpl and built here. I see no difference in results between optimised and debug.
I'm retrying with a fresh pull. 

Interesting to me:

I/GeckoApp(10048): Startup mode: NORMAL
E/GeckoLinker(10048): /data/app/org.mozilla.fennec-1.apk!/libmozalloc.so: Warning: relocation to NULL @0x00003e2c
E/GeckoLinker(10048): /data/app/org.mozilla.fennec-1.apk!/libmozalloc.so: Warning: relocation to NULL @0x00003db8 for symbol "__cxa_begin_cleanup"
E/GeckoLinker(10048): /data/app/org.mozilla.fennec-1.apk!/libmozalloc.so: Warning: relocation to NULL @0x00003de0 for symbol "__cxa_type_match"
E/GeckoLibLoad(10048): Loaded libs in 635ms total, 310ms user, 150ms system, 0 faults
W/GeckoThread(10048): zerdatime 2946177 - runGecko
I/GeckoThread(10048): RunGecko - URI = null
I/GeckoAppShell(10048): post native init
I/GeckoAppShell(10048): setLayerClient called
E/GeckoConsole(10048): Could not read chrome manifest 'file:///data/data/org.mozilla.fennec/chrome.manifest'.
E/Handler (10048): Failed to handle callback; interface not implemented, callback:org.mozilla.gecko.GeckoAppShell$17@40e11860
E/Handler (10048): 	at org.mozilla.gecko.GeckoAppShell$17.run(GeckoAppShell.java:2160)
E/Handler (10048): 	at org.mozilla.gecko.GeckoAppShell.pumpMessageLoop(GeckoAppShell.java:2165)
E/Handler (10048): 	at org.mozilla.gecko.GeckoAppShell.nativeRun(Native Method)
E/Handler (10048): 	at org.mozilla.gecko.GeckoAppShell.nativeRun(Native Method)
E/Handler (10048): 	at org.mozilla.gecko.GeckoAppShell.runGecko(GeckoAppShell.java:503)
E/Handler (10048): 	at org.mozilla.gecko.GeckoThread.run(GeckoThread.java:112)
Which is the line Looper.loop() in the following snippet:

        sGeckoHandler.post(new Runnable() {
            public void run() {
                throw new RuntimeException();
            }
        });

        try {
            Looper.loop();
        } catch(Exception ex) {}
    }
Er, actually the line that is throwing the error is "throw new RuntimeException()" - I wonder whether that's just expected.
Joe produced a try build for testing https://tbpl.mozilla.org/?tree=Try&rev=e5f988326565
I've tried the above patch on the HTC One X, Galaxy Nexus, HTC Incredible, and LG Optimus G2x. That is every phone I have here besides the Droid Pro, which won't turn on (sigh). The patch fixes the bug on the HTC One X without regressing any of the other mentioned devices.
Comment on attachment 621824 [details] [diff] [review]
Improve the exit procedure for the Gecko Android Looper

Review of attachment 621824 [details] [diff] [review]:
-----------------------------------------------------------------

no more or less hacky than it was before
Attachment #621824 - Flags: review?(blassey.bugs) → review+
Whiteboard: [inbound]
https://hg.mozilla.org/mozilla-central/rev/56ffdd5c9388
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 15
Comment on attachment 621824 [details] [diff] [review]
Improve the exit procedure for the Gecko Android Looper

[Triage Comment]
Attachment #621824 - Flags: approval-mozilla-aurora+
Tested the latest moz-central build (presumably including this patch) and it works fine on my One X.

Cheers!
Whiteboard: [inbound]
Status: RESOLVED → VERIFIED
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.