xpcshell crashes on Android 7 (ARM device and ARM and x86 emulators)
Categories
(Core :: JavaScript Engine, defect, P3)
Tracking
()
People
(Reporter: gbrown, Assigned: snorp)
References
(Blocks 1 open bug)
Details
(Keywords: crash, Whiteboard: [geckoview:p1])
Attachments
(2 files)
![]() |
Reporter | |
Comment 1•7 years ago
|
||
![]() |
Reporter | |
Comment 2•7 years ago
|
||
![]() |
Reporter | |
Updated•7 years ago
|
![]() |
Reporter | |
Updated•7 years ago
|
Comment 3•7 years ago
|
||
Comment 4•7 years ago
|
||
Assignee | ||
Comment 5•7 years ago
|
||
![]() |
Reporter | |
Comment 6•7 years ago
|
||
![]() |
Reporter | |
Comment 7•7 years ago
|
||
Comment 8•7 years ago
|
||
Comment 9•7 years ago
|
||
Updated•7 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
Comment 11•7 years ago
|
||
![]() |
Reporter | |
Comment 12•7 years ago
|
||
Comment 13•7 years ago
|
||
![]() |
Reporter | |
Updated•7 years ago
|
Comment 14•7 years ago
|
||
Comment 15•6 years ago
|
||
Comment 16•6 years ago
|
||
Steven, does the SpiderMonkey team own the xpcshell tests? They're failing on Android 7 (ARM devices and x86 emulator), but not on Android 4.3 ARM emulator. The test failure might be a file permissions problem.
Comment 17•6 years ago
|
||
Ted, do you know who might be a good person on our team to look at this? Do we have someone that knows xpcshell on our team?
Comment 18•6 years ago
|
||
In theory, xpcshell and the test-runner are owned by XPConnect https://wiki.mozilla.org/Modules/Core#XPConnect. These android-specific tooling falls between gaps.
I am unable to reproduce this myself. (Physical devices fail without rooting, and |./mach android-emulator --version 7.0| never finishes starting up and mounting an /sdcard).
Nothing seems to indicate SpiderMonkey is particularly related here. If I had to speculate, based on Comment 4 where we crash in |operator new| during initial loading, I would say that the allocator-interception code is failuring with the libc that exists on the Android 7 image. It is possible there is some odd configuration of how the xpcshell binary is generated that is making us hit it.
Someone with Android build system and linker understanding should probably look at this.
Comment 19•6 years ago
|
||
I'll reset the [geckoview] whiteboard priority so the GeckoView team will revisit this bug in our triage meeting.
Comment 20•6 years ago
|
||
James will take a look. This is probably some new permission restriction in Android 7.
Comment 21•6 years ago
|
||
FWIW I could not get the plain JS shell to run on newer Android versions, same symptom - SEGV on startup when running out of /data/local/tmp via adb shell (device not rooted or otherwise mucked with). But I never took it into a debugger to find out more.
Comment 22•6 years ago
|
||
I wonder if this is related: https://developer.android.com/about/versions/nougat/android-7.0-changes#ndk
Updated•6 years ago
|
Comment 23•6 years ago
|
||
This is a shot in the dark, but over in Bug 1525661, I found many inscrutable issues when running out of a profile directory that is not writable. Different emulators have different permissions, and I wonder if we're seeing something like this? I expect a debugger would reveal if this was the cause almost immediately.
![]() |
Reporter | |
Comment 24•6 years ago
|
||
(In reply to Geoff Brown [:gbrown] from comment #6)
Note that cppunit tests run fine for me on the same 7.0 emulator...why are
they different?
Actually, there are a few startup crashes on 7.0; glandium is having a look at those in bug 1530874.
![]() |
Reporter | |
Comment 25•6 years ago
|
||
Updated try run, now complete with tombstones (saved as artifacts):
![]() |
Reporter | |
Comment 26•6 years ago
|
||
I stumbled on this curiosity: If I build locally with this mozconfig, xpcshell does not crash on startup on the 7.0 x86 emulator, and many tests pass:
ac_add_options --enable-application=mobile/android
ac_add_options --target=x86_64
export MOZILLA_OFFICIAL=1
CC="/home/gbrown/.mozbuild/clang/bin/clang"
CXX="/home/gbrown/.mozbuild/clang/bin/clang++"
ac_add_options --with-android-ndk="/home/gbrown/.mozbuild/android-ndk-r17b"
mk_add_options MOZ_OBJDIR=/home/gbrown/objdirs/x86_64-debug
mk_add_options AUTOCLOBBER=1
If I uncomment MOZILLA_OFFICIAL, the startup crash returns.
I cannot demonstrate this on try: If I remove MOZILLA_OFFICIAL from the nightly mozconfig, gradle fails at build time:
Comment 27•6 years ago
|
||
(In reply to Geoff Brown [:gbrown] from comment #26)
I stumbled on this curiosity: If I build locally with this mozconfig, xpcshell does not crash on startup on the 7.0 x86 emulator, and many tests pass:
ac_add_options --enable-application=mobile/android
ac_add_options --target=x86_64export MOZILLA_OFFICIAL=1
CC="/home/gbrown/.mozbuild/clang/bin/clang"
CXX="/home/gbrown/.mozbuild/clang/bin/clang++"
ac_add_options --with-android-ndk="/home/gbrown/.mozbuild/android-ndk-r17b"
mk_add_options MOZ_OBJDIR=/home/gbrown/objdirs/x86_64-debug
mk_add_options AUTOCLOBBER=1If I uncomment MOZILLA_OFFICIAL, the startup crash returns.
I cannot demonstrate this on try: If I remove MOZILLA_OFFICIAL from the nightly mozconfig, gradle fails at build time:
The Gradle failure just has to do with dependencies:
[task 2019-03-11T19:12:55.311Z] 19:12:55 INFO - > Could not find com.squareup.leakcanary:leakcanary-android:1.4-beta1.
We could make that work if we wanted to; or just work around it here: https://searchfox.org/mozilla-central/source/mobile/android/app/build.gradle#246.
MOZILLA_OFFICIAL changes many things so I don't think it'll be all that helpful for narrowing down the behaviour. Is it really this hard to track down a startup crash in an xpcshell test on Android? (I ask honestly: I don't know, I've never tried.)
Updated•6 years ago
|
![]() |
Reporter | |
Comment 28•6 years ago
|
||
This goes away with the fix from bug 1530874.
Description
•