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

Status: RESOLVED FIXED

(Core :: mozglue, defect)

Description

[Kartikaya Gupta (email:[e-mail])]

Attachment: 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.

Comment 1

[Kartikaya Gupta (email:[e-mail])]

Attachment: Patch I applied for more debugging info

Comment 2

[Mike Hommey [:glandium]]

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.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

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?

Comment 4

[Mike Hommey [:glandium]]

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.

Comment 5

[Mike Hommey [:glandium]]

Attachment: 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?

Comment 6

[Kartikaya Gupta (email:[e-mail])]

Attachment: Logcat with patch/makefile change

It still fails, here is the logcat.

Comment 7

[Mike Hommey [:glandium]]

(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))

Comment 8

[Kartikaya Gupta (email:[e-mail])]

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

Comment 9

[Kartikaya Gupta (email:[e-mail])]

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..)

Comment 10

[Mike Hommey [:glandium]]

http://hg.mozilla.org/mozilla-central/rev/bd0392b4564e

Comment 11

[Mike Hommey [:glandium]]

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

Comment 12

[Alex Keybl [:akeybl]]

Leaving in the queue, as it's not clear where ARMv6 will be uplifted to at this point.

Comment 13

[Alex Keybl [:akeybl]]

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.