[ARMv6] armv6 build doesn't work on Motorola Backflip with cyanogenmod gingerbread

RESOLVED FIXED in mozilla16

Status

()

Core
mozglue
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: kats, Assigned: glandium)

Tracking

Trunk
mozilla16
ARM
Android
Points:
---

Firefox Tracking Flags

(firefox15 affected)

Details

(Whiteboard: [ARMv6])

Attachments

(4 attachments)

Created attachment 641063 [details]
Logcat from startup

I have a Motorola Backflip which I've rooted and installed cyanogenmod 7.1.0 (equivalent to android 2.3.7) on. It's an ARMv6 phone with little memory/storage, so it's entirely possible that firefox won't be supported on this phone. However, I tried running the armv6 build on it and it failed to start up properly. Logcat indicates that the attempt to mmap libmozsqlite3.so fails, resulting a gecko not starting up properly.

I've attached a logcat of the output. Note that in order to get more debugging information I made some changes to mozglue/linker/CustomElf.cpp, I will attach that patch as well.
Created attachment 641064 [details] [diff] [review]
Patch I applied for more debugging info
(Assignee)

Comment 2

5 years ago
Looks like you are hitting bug 723939, but the workaround from it doesn't work on your phone. Or maybe the build part of bug 723939 somehow fails on the mozilla armv6 builds.
So the patch in bug 723939 changes one of the mmap calls in CustomElf.cpp, but the error I'm seeing happens at the other mmap call (the one in LoadSegment). Does the same patch need to be applied there?
(Assignee)

Comment 4

5 years ago
Note the same patch, because it would just break everything, but it's definitely the same problem. I'm surprised we didn't run into that earlier.
(Assignee)

Updated

5 years ago
Assignee: nobody → mh+mozilla
(Assignee)

Comment 5

5 years ago
Created attachment 641090 [details] [diff] [review]
Avoid failure to mmap some library segments on some armv6 devices

Can you try this patch with an additional
DEFINES += -DMOZ_DEBUG_LINKER
in mozglue/linker/Makefile.in?
Created attachment 641095 [details]
Logcat with patch/makefile change

It still fails, here is the logcat.
(Assignee)

Comment 7

5 years ago
(In reply to Kartikaya Gupta (:kats) from comment #6)
> Created attachment 641095 [details]
> Logcat with patch/makefile change
> 
> It still fails, here is the logcat.

Can you check if you have -Wl,-z,max-page-size=0x4000 in your LDFLAGS?

If you do, can you add some logging to know which one of these you are hitting?
+    if ((mapped != MAP_FAILED) || (pt_load->p_vaddr == 0) ||
+        (pt_load->p_align == align))
objdir/config/autoconf.mk has this:

OS_LDFLAGS  =  -mandroid -L/home/kats/android/ndk/platforms/android-5/arch-arm/usr/lib -Wl,-rpath-link=/home/kats/android/ndk/platforms/android-5/arch-arm/usr/lib --sysroot=/home/kats/android/ndk/platforms/android-5/arch-arm -llog -Wl,--allow-shlib-undefined  -L/home/kats/zspace/mozilla-git/obj-android/build/stlport -L/home/kats/android/ndk/sources/cxx-stl/stlport/libs/armeabi/ -Wl,-z,noexecstack -Wl,--icf=safe -Wl,-z,max-page-size=0x4000

So yes, it has those flags at the end.

I added the following code to test the three conditions independently:

diff --git a/mozglue/linker/CustomElf.cpp b/mozglue/linker/CustomElf.cpp
index 9b3083d..8d11e4b 100644
--- a/mozglue/linker/CustomElf.cpp
+++ b/mozglue/linker/CustomElf.cpp
@@ -406,6 +406,15 @@ CustomElf::LoadSegment(const Phdr *pt_load) const
     mapped = mappable->mmap(where, pt_load->p_filesz + align_offset,
                             prot, MAP_PRIVATE | MAP_FIXED,
                             pt_load->p_offset - align_offset);
+    if (mapped != MAP_FAILED) {
+      log("staktrace: mapped is not MAP_FAILED, it is %x", mapped);
+    }
+    if (pt_load->p_vaddr == 0) {
+      log("staktrace: pt_load->p_vaddr is zero");
+    }
+    if (pt_load->p_align == align) {
+      log("staktrace: pt_load->p_align == align, %x", align);
+    }
     if ((mapped != MAP_FAILED) || (pt_load->p_vaddr == 0) ||
         (pt_load->p_align == align))
       break;

And got the following output in the logcat (filtered by GeckoLinker):

07-11 13:58:58.819 E/GeckoLinker( 2556): /data/app/org.mozilla.fennec_kats-2.apk!/libmozsqlite3.so: Warning: program header type #1879048193 not handled
07-11 13:58:58.829 E/GeckoLinker( 2556): /data/app/org.mozilla.fennec_kats-2.apk!/libmozsqlite3.so: Loading segment @0x469c0000 r-x
07-11 13:58:59.069 E/GeckoLinker( 2556): cacheflush(0x46940000, 0x469b96d8)
07-11 13:58:59.079 E/GeckoLinker( 2556): staktrace: mapped is not MAP_FAILED, it is 469c0000
07-11 13:58:59.079 E/GeckoLinker( 2556): staktrace: pt_load->p_vaddr is zero
07-11 13:58:59.079 E/GeckoLinker( 2556): staktrace: pt_load->p_align == align, 1000
07-11 13:58:59.079 E/GeckoLinker( 2556): /data/app/org.mozilla.fennec_kats-2.apk!/libmozsqlite3.so: Loading segment @0x46a3a000 rw-
07-11 13:58:59.079 E/GeckoLinker( 2556): staktrace: pt_load->p_align == align, 1000
07-11 13:58:59.079 E/GeckoLinker( 2556): /data/app/org.mozilla.fennec_kats-2.apk!/libmozsqlite3.so: Failed to mmap
Building with the default NDK linker (as opposed to gold) fixes the above problem and libmozsqlite3.so seems to be loaded correctly. (Firefox still doesn't render stuff but I think it's a graphics problem now..)
(Assignee)

Updated

5 years ago
Attachment #641090 - Flags: review?(nfroyd)
(Assignee)

Updated

5 years ago
Component: General → mozglue
Product: Firefox for Android → Core

Updated

5 years ago
Whiteboard: [ARMv6]
Attachment #641090 - Flags: review?(nfroyd) → review+
(Assignee)

Comment 10

5 years ago
http://hg.mozilla.org/mozilla-central/rev/bd0392b4564e
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla16
(Assignee)

Updated

5 years ago
status-firefox15: --- → affected
(Assignee)

Comment 11

5 years ago
Comment on attachment 641090 [details] [diff] [review]
Avoid failure to mmap some library segments on some armv6 devices

[Approval Request Comment]
Bug caused by hardware requirement on some ARMv6 devices not fitted by our libraries 
User impact if declined: Crash at startup on some ARMv6 devices
Testing completed (on m-c, etc.): tested locally by kats
Risk to taking this patch (and alternatives if risky): It doesn't change anything for ARMv7 builds. Worst case, it doesn't fix all broken cases. IOW, low risk.
String or UUID changes made by this patch: None
Attachment #641090 - Flags: approval-mozilla-beta?
Leaving in the queue, as it's not clear where ARMv6 will be uplifted to at this point.
Comment on attachment 641090 [details] [diff] [review]
Avoid failure to mmap some library segments on some armv6 devices

No need to take this on beta - ARMv6 is shipping first in 16.
Attachment #641090 - Flags: approval-mozilla-beta? → approval-mozilla-beta-
You need to log in before you can comment on or make changes to this bug.