882608 - Segfault with MOZ_LINKER_ONDEMAND=0

Status: RESOLVED FIXED

(Core :: mozglue, defect)

Description

[Julian Seward [:jseward]]

Same setup as bug 882329.

Starting like this:

adb shell rm /data/data/org.mozilla.fennec/cache/*.so ; \
  adb logcat -c ; \
  adb shell sh /system/bin/am start -S \
    -n org.mozilla.fennec/.App \
    --es env0 MOZ_PROFILER_INTERVAL=50 \
    --es env1 MOZ_PROFILER_MODE=native \
    --es env2 MOZ_PROFILER_NEW=1 \ 
    --es env3 MOZ_PROFILER_VERBOSE=1 \
    --es env4 MOZ_LINKER_ONDEMAND=0 ; \
    adb logcat 2>&1 | cat

reliably leads to this, at startup:

F/libc    (29953): Fatal signal 11 (SIGSEGV) at 0x00010101 (code=1)

whereas changing MOZ_LINKER_ONDEMAND=1 produces up-and-running
stable Fennec.

This and bug 882329 combined make a bad combination for me.  882329
means I can't use JimDB to investigate segfaults in Fennec.  This
bug means I can't use Valgrind to investigate segfaults in Fennec,
because Valgrind can't provide precise-exception support needed by
_ONDEMAND=1.  And the segfault I am looking for doesn't happen with
MOZ_LINKER_EXTRACT=1.

Comment 1

[Julian Seward [:jseward]]

V produces the following unhelpful output:

I/start_valgrind_fennec(30662): ==30663== Thread 14:
I/start_valgrind_fennec(30662): ==30663== Invalid read of size 4
I/start_valgrind_fennec(30662): ==30663==    at 0x291F601E: ??? (in /dev/ashmem)
I/start_valgrind_fennec(30662): ==30663==    by 0x291F5FE5: ??? (in /dev/ashmem)
I/start_valgrind_fennec(30662): ==30663==    by 0x291F419F: ??? (in /dev/ashmem)
I/start_valgrind_fennec(30662): ==30663==    by 0x291F6DF5: ??? (in /dev/ashmem)
I/start_valgrind_fennec(30662): ==30663==    by 0x24D13527: ??? (in /dev/ashmem)
I/start_valgrind_fennec(30662): ==30663==    by 0x291D636F: ??? (in /dev/ashmem)
I/start_valgrind_fennec(30662): ==30663==    by 0x24D0797B: ??? (in /dev/ashmem)
I/start_valgrind_fennec(30662): ==30663==    by 0x28517549: ??? (in /dev/ashmem)
I/start_valgrind_fennec(30662): ==30663==    by 0x2851A709: ??? (in /dev/ashmem)
I/start_valgrind_fennec(30662): ==30663==    by 0x2851A881: ??? (in /dev/ashmem)
I/start_valgrind_fennec(30662): ==30663==    by 0x5466D8B: dvmLinkClass(ClassObject*) (/home/sewardj/AND4-xxray/dalvik/vm/oo/Class.cpp:2851)
I/start_valgrind_fennec(30662): ==30663==    by 0x22B5F01D: ??? (in /dev/ashmem)
I/start_valgrind_fennec(30662): ==30663==  Address 0x10101 is not stack'd, malloc'd or (recently) free'd
I/start_valgrind_fennec(30662): ==30663== 
F/libc    (30663): Fatal signal 11 (SIGSEGV) at 0x00010101 (code=1)

Comment 2

[Julian Seward [:jseward]]

Possibly related to bug 882903 ?

Comment 3

[Mike Hommey [:glandium]]

This is due to bug 875824. I just hit this today, it happens because the first PT_LOAD ends before the end of a page, and the following PT_LOAD starts before the end of the same page. There is code in MappableSeekableZStream::ensure to handle this case, but it only works if all mappings already exist, but the code from bug 875824 calls ensure on all pages while creating the mappings, so when handling the last page of the first PT_LOAD, it doesn't know there's the other PT_LOAD that requires the same page (which it does when not using MOZ_LINKER_ONDEMAND=0)

Comment 4

[Mike Hommey [:glandium]]

Attachment: Fix various issues in faulty.lib with incomplete pages and MOZ_LINKER_ONDEMAND=0

Comment 5

[Julian Seward [:jseward]]

I verified that (m-c + this patch) removes the invalid reads shown in
comment #1, whereas m-c alone still has them.  IOW LGTM.

Comment 6

[Mike Hommey [:glandium]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/d7a7b56432fb

Comment 7

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/d7a7b56432fb