Closed Bug 882608 Opened 9 years ago Closed 9 years ago

Segfault with MOZ_LINKER_ONDEMAND=0

Categories

(Core :: mozglue, defect)

ARM
Android
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla25

People

(Reporter: jseward, Assigned: glandium)

References

Details

Attachments

(1 file)

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.
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)
Possibly related to bug 882903 ?
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)
Assignee: nobody → mh+mozilla
Blocks: 875824
I verified that (m-c + this patch) removes the invalid reads shown in
comment #1, whereas m-c alone still has them.  IOW LGTM.
Attachment #776995 - Flags: review?(nfroyd) → review+
https://hg.mozilla.org/mozilla-central/rev/d7a7b56432fb
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
You need to log in before you can comment on or make changes to this bug.