Closed Bug 920558 Opened 6 years ago Closed 6 years ago

Fennec (Sep 25 nightly) doesn't start up properly on a Galaxy Q running Android 2.3

Categories

(Firefox for Android :: General, defect)

All
Android
defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 27
Tracking Status
firefox27 --- verified

People

(Reporter: kats, Unassigned)

References

Details

Attachments

(5 files)

Attached file Logcat
Yesterday's nightly was working fine, but today's is broken. When I start Fennec the UI starts up but gecko never loads properly so I can't load any pages or go to the settings. Logcat has the attached error.
Bisecting m-c builds shows the breakage occurred between 57d160eda301 and ce5bc913350a. I'll have to bisect inbound since that's a pretty big range.
Inbound range: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2f924314efe8&tochange=cdba23acd0e0

I'm gonna guess bug 916923 but I'll keep narrowing the range as much as I can. Nathan, let me know if you want me to do a local debug build or something.
Urgh. Mid-aired with Kevin.

I verified cdba23acd0e0 works, so it's definitely one of the three patches Nathan pushed.
Blocks: 916923
Can you get more information, via something like:

adb shell am start -a android.activity.MAIN -n org.mozilla.fennec_kats/.App --es env0 MOZ_DEBUG_LINKER=1

and provide interesting-looking messages from logcat?  Wondering if somebody is actually following the MAP_FIXED manpage documentation...

Additionally, I would be interested to know whether https://bugzilla.mozilla.org/attachment.cgi?id=808822 works any better for you.
Flags: needinfo?(bugmail.mozilla)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #4)
> I verified cdba23acd0e0 works, so it's definitely one of the three patches
> Nathan pushed.

I really meant to say b5d45a95d4ba worked.

For some reason I'm getting a build error trying to build ARMv6 locally. I suspect the buildbot mozconfig has drifted pretty far from the mozconfig I usually use that it'll take a while to figure out how to sync mine up again. I'll push builds to tryserver in parallel with figuring that out. Leaving the needinfo until I have results.
So I neglected to realize that try doesn't do debug builds of armv6. My local build is failing on netwerk/sctp/src/netinet/sctp_indata.c (among other files) for what appears to be a compiler error. I'm using the 4.7 toolchain in NDK r8e on linux x86_64. I might try building it on my Mac later tonight if I can't figure this out before then.
Flags: needinfo?(bugmail.mozilla)
Flags: needinfo?(bugmail.mozilla)
Attached file busted compiler output
Also for the record this is the compile error I'm seeing. The assembly generated by the compiler contains an offset that doesn't assemble. I verified this by compiling with -S and then running the .S back through gcc. There's an instruction "ldr r4, .L1052" at the first error and "ldr r3, .L1052+32" at the second.
Ok, so I ended up building a non-debug build and got the output with MOZ_DEBUG_LINKER=1. I can probably rebuild just the mozglue/linker folder with debug enabled if that helps more. I'll try the other patch as well.
Flags: needinfo?(bugmail.mozilla)
My guess is that the patch from bug 920558 is breaking the fix for bug 723939.
Attachment #810138 - Attachment mime type: text/x-vhdl → text/plain
(In reply to Mike Hommey [:glandium] from comment #10)
> My guess is that the patch from bug 920558 is breaking the fix for bug
> 723939.

In fact it fails before that, but for the same reason. I think the simplest to do here is to #ifndef __ARM__ for the page added in bug 920558.
This is the output using the patch from https://bug916923.bugzilla.mozilla.org/attachment.cgi?id=808822 instead of the one that actually landed. It crashes completely on startup.
Attachment #810144 - Attachment mime type: text/x-vhdl → text/plain
Relatedly, what would it take to have automated test coverage on armv6?
(In reply to Mike Hommey [:glandium] from comment #11)
> (In reply to Mike Hommey [:glandium] from comment #10)
> > My guess is that the patch from bug 920558 is breaking the fix for bug
> > 723939.
> 
> In fact it fails before that, but for the same reason. I think the simplest
> to do here is to #ifndef __ARM__ for the page added in bug 920558.

Surely you mean bug 916923, not this bug?
(In reply to Nathan Froyd (:froydnj) from comment #14)
> Surely you mean bug 916923, not this bug?

Indeed.
I have also bisected a startup failure on an old ARMv6 phone
to bug 916923.  It would appear that the kernel only supports
mmap of the ashmem for the MAP_SHARED case without a fixed
mapping.  The kernel version is 2.6.35
I mentioned mapping an extra 16k prior to the file last night on IRC as a
preferable solution to using #ifdef.  But after I thought about it, I
decided that wasting 20k per mapped section probably was a little over the
top.

So here's a solution with #ifdefs; the ARM section is identical to what we
had before (modulo use of AlignedEndPtr), and the x86 section is close to
what we have now, only we now have to map slightly less.

A try run looks good, but since I screwed up my options and did talos tests
instead of unit tests, I'll have to re-run to see if I can get things to
fail for x86 Android and verify that crash reports still work there.
Attachment #810660 - Flags: review?(mh+mozilla)
Comment on attachment 810660 [details] [diff] [review]
map anonymous pages differently on ARM and x86

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

::: mozglue/linker/Mappable.cpp
@@ +190,2 @@
>       */
> +#if defined(__ARMEL__) || defined(__ARMEB__)

__arm__

@@ +258,5 @@
>  
>  #ifdef ANDROID
>    ~_MappableBuffer() {
> +    /* Free the additional page we allocated. See _MappableBuffer::Create */
> +#if defined(__ARMEL__) || defined(__ARMEB__)

__arm__
Attachment #810660 - Flags: review?(mh+mozilla) → review+
A local build with this patch fixes the problem on my Galaxy Q. Thanks!
https://hg.mozilla.org/mozilla-central/rev/a1ea604002b6
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 27
Fennec 27.0a1 (09/30) using LG Slider 

The app is now usable, I am able to load page, browse without issues.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.