Closed Bug 1529034 Opened 6 years ago Closed 6 years ago

Perma tier2 tests/jit-test/jit-test/tests/auto-regress/bug1263857.js | Segmentation fault (code 139, args "--ion-eager --ion-offthread-compile=off --more-compartments") [0.3 s]

Categories

(Core :: JavaScript Engine, defect, P5)

Product:
Core
Component:
JavaScript Engine
Platform:
ARM64
Android
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla67
Tracking Flags:
Tracking Status
firefox-esr60 --- unaffected
firefox65 --- unaffected
firefox66 --- unaffected
firefox67 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: sstangl)

References

(Blocks 1 open bug)

Details

(Keywords: regression, Whiteboard: [arm64:m2] [stockwell unknown])

Attachments

(1 file, 1 obsolete file)

Bug 1529034 - Just punt on auto-regress/bug1263857.js. r=nbp
47 bytes, text/x-phabricator-request
Details | Review

#[markdown(off)]
Filed by: rgurzau [at] mozilla.com

https://treeherder.mozilla.org/logviewer.html#?job_id=229248474&repo=autoland

https://queue.taskcluster.net/v1/task/bpYKUFpkRb-KR2HSMhb8cA/runs/0/artifacts/public/logs/live_backing.log

17:12:27 INFO - TEST-PASS | tests/jit-test/jit-test/tests/auto-regress/bug1263857.js | Success (code 3, args "") [0.2 s]
17:12:27 INFO - {"action": "test_start", "jitflags": "", "pid": 431, "source": "jittests", "test": "auto-regress/bug1263857.js", "thread": "main", "time": 1550596347.0824301}
17:12:27 INFO - {"action": "test_end", "extra": {"jitflags": ""}, "jitflags": "", "message": "Success", "pid": 431, "source": "jittests", "status": "PASS", "test": "auto-regress/bug1263857.js", "thread": "main", "time": 1550596347.287142}
17:12:27 INFO - Segmentation faultSegmentation faultExit code: 139
17:12:27 INFO - FAIL - auto-regress/bug1263857.js
17:12:27 WARNING - TEST-UNEXPECTED-FAIL | tests/jit-test/jit-test/tests/auto-regress/bug1263857.js | Segmentation fault (code 139, args "--ion-eager --ion-offthread-compile=off --more-compartments") [0.3 s]
17:12:27 INFO - {"action": "test_start", "jitflags": "--ion-eager --ion-offthread-compile=off --more-compartments", "pid": 431, "source": "jittests", "test": "auto-regress/bug1263857.js", "thread": "main", "time": 1550596347.288394}
17:12:27 INFO - {"action": "test_end", "extra": {"jitflags": "--ion-eager --ion-offthread-compile=off --more-compartments"}, "jitflags": "--ion-eager --ion-offthread-compile=off --more-compartments", "message": "Segmentation fault", "pid": 431, "source": "jittests", "status": "FAIL", "test": "auto-regress/bug1263857.js", "thread": "main", "time": 1550596347.592977}
17:12:27 INFO - INFO exit-status : 139
17:12:27 INFO - INFO timed-out : False
17:12:27 INFO - INFO stdout > Segmentation fault
17:12:27 INFO - INFO stderr 2> Segmentation fault
17:12:27 INFO - adb_returncode=139
17:12:27 INFO - Segmentation faultadb_returncode=139
17:12:27 INFO - Segmentation faultExit code: 139
17:12:27 INFO - FAIL - auto-regress/bug1263857.js
17:12:27 WARNING - TEST-UNEXPECTED-FAIL | tests/jit-test/jit-test/tests/auto-regress/bug1263857.js | adb_returncode=139 (code 139, args "--ion-eager --ion-offthread-compile=off --ion-check-range-analysis --ion-extra-checks --no-sse3 --no-threads") [0.2 s]
17:12:27 INFO - {"action": "test_start", "jitflags": "--ion-eager --ion-offthread-compile=off --ion-check-range-analysis --ion-extra-checks --no-sse3 --no-threads", "pid": 431, "source": "jittests", "test": "auto-regress/bug1263857.js", "thread": "main", "time": 1550596347.59424}
17:12:27 INFO - {"action": "test_end", "extra": {"jitflags": "--ion-eager --ion-offthread-compile=off --ion-check-range-analysis --ion-extra-checks --no-sse3 --no-threads"}, "jitflags": "--ion-eager --ion-offthread-compile=off --ion-check-range-analysis --ion-extra-checks --no-sse3 --no-threads", "message": "adb_returncode=139", "pid": 431, "source": "jittests", "status": "FAIL", "test": "auto-regress/bug1263857.js", "thread": "main", "time": 1550596347.798707}
17:12:27 INFO - INFO exit-status : 139
17:12:27 INFO - INFO timed-out : False
17:12:27 INFO - INFO stdout > adb_returncode=139
17:12:27 INFO - INFO stdout > Segmentation fault
17:12:27 INFO - INFO stderr 2> adb_returncode=139
17:12:27 INFO - INFO stderr 2> Segmentation fault
17:12:28 INFO - adb_returncode=139
17:12:28 INFO - Segmentation faultadb_returncode=139
17:12:28 INFO - Segmentation faultExit code: 139
17:12:28 INFO - FAIL - auto-regress/bug1263857.js

Thanks. This appears to only reproduce on the Pixel 2, and not on the OverDrive.

The test appears to be GC-related, so it might repro in low-memory environments.

Blocks: arm64-ion-tests

In the simulator, it just shows:

uncaught exception: out of memory
(Unable to print stack trace)
OS: Unspecified → Android
Hardware: Unspecified → ARM64

After instrumenting the ARM64 Simulator to emulate D&I cache coherency, I got this test case in the list of failing test cases.
I will investigate it with this instrumented Simulator (Bug 1441436).

Assignee: nobody → nicolas.b.pierron
Status: NEW → ASSIGNED
Summary: Perma tests/jit-test/jit-test/tests/auto-regress/bug1263857.js | Segmentation fault (code 139, args "--ion-eager --ion-offthread-compile=off --more-compartments") [0.3 s] → Perma tier2 tests/jit-test/jit-test/tests/auto-regress/bug1263857.js | Segmentation fault (code 139, args "--ion-eager --ion-offthread-compile=off --more-compartments") [0.3 s]
Whiteboard: [stockwell needsork:owner]
status-firefox65: --- → unaffected
status-firefox66: --- → unaffected
status-firefox67: --- → affected
status-firefox-esr60: --- → unaffected
Whiteboard: [stockwell needsork:owner] → [stockwell needswork:owner] [arm64:m2]

(In reply to Nicolas B. Pierron [:nbp] from comment #3)

After instrumenting the ARM64 Simulator to emulate D&I cache coherency, I got this test case in the list of failing test cases.
I will investigate it with this instrumented Simulator (Bug 1441436).

This was a false positive of my the instrumentation. I cannot reproduce it anymore.

Assignee: nicolas.b.pierron → nobody
Status: ASSIGNED → NEW

(In reply to Sean Stangl [:sstangl] from comment #1)

Thanks. This appears to only reproduce on the Pixel 2, and not on the OverDrive.

The test appears to be GC-related, so it might repro in low-memory environments.

How likely do we expect such low-memory environments to happen in the real world? Is it worth the effort to simulate such an environment so can fix the root cause here?

Flags: needinfo?(sstangl)

Nicolas could you look into this? Since you are looking at other things in the simulator.

Flags: needinfo?(sstangl) → needinfo?(nicolas.b.pierron)

How likely do we expect such low-memory environments to happen in the real world? Is it worth the effort to simulate such an environment so can fix the root cause here?

Well, we'll have to. This is the last remaining blocker for landing ARM64 Ion.

I think the low-memory thing was a red herring. It does not reproduce even in low-memory non-Pixel2 environments.

Note that in https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=240f53dcb5e6ed5a770b854be6c242c1bae4d75c&selectedJob=229252260 it reproduces with just --baseline-eager.

(In reply to Steven DeTar [:sdetar] from comment #8)

Nicolas could you look into this? Since you are looking at other things in the simulator.

I was not able to catch it with the simulator, as mentioned in comment 5.

So far it only reproduce on the pixel 2, would it be possible to have one of these pixel 2 ship to Sean or me to investigate this issue. Either remotely or in-person?

Flags: needinfo?(nicolas.b.pierron) → needinfo?(sdetar)

Sean, do you know if we can download the generated Aarch64 binary to test it on softIron devices? (this might imply some LD_PRELOAD to make it work)

Flags: needinfo?(sstangl)

It works on SoftIron devices. I am currently attempting to statically link a shell executable built on Fedora ARM64 and run it on an Android phone through adb.

Flags: needinfo?(sstangl)

Static linking doesn't work. I don't think we can download the generated binary... will keep asking around.

Mossop on IRC confirmed that the "Android 8.0 Pixel2 AArch64 opt" tests are using the binary built during the "Android 5.0 AArch64 opt" stage.

The binary can be downloaded here (from a Try push of mine): https://queue.taskcluster.net/v1/task/NbZDCSTxREi24EltxecuhA/runs/0/artifacts/public/build/target.jsshell.zip

In general, it can be downloaded by clicking on the "B", selecting "Job Details", searching for "artifact uploaded: target.jsshell.zip", and clicking that link.

No luck loading it on the SoftIron. It's identified as ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /system/bin/linker64, BuildID[sha1]=6f8c7b694432a1627d5e7c202a4c2c3f938d02ea, stripped, but various tools believe the ELF headers are malformed.

I tried the following:

  1. sudo cp /lib/ld-linux-aarch64.so.1 /system/bin/linker64 (another option is to use Nix' patchelf but the target string is longer than the source string).
  2. git clone https://github.com/innogames/android-ndk [1.5GB download] (I put as ~/dev/android-ndk).
  3. LD_LIBRARY_PATH="/home/sstangl/dev/android-ndk/platforms/android-24/arch-arm64/usr/lib" LD_PRELOAD="$PWD/libmozglue.so" ./js

But in the end it just gives a bus error, so I guess the environment really just isn't compatible.

I got it loaded onto a Motorola Moto G5, but still am not able to execute it:

1|cedric:/data/local/tmp $ pwd
/data/local/tmp
cedric:/data/local/tmp $ ls
js libmozglue.so libnss3.so 
cedric:/data/local/tmp $ ./js
/system/bin/sh: ./js: not executable: 64-bit ELF file

The CPU is a Cortex A53, a 64-bit chip.

Hm, this Android does not appear to have /system/bin/linker64.

The Moto G5 is useless for 64-bit; it was mis-advertised. The processor is 64-bit capable, but the userland is 32-bit only.

Good news, though:

1|sailfish:/data/local/tmp $ LD_LIBRARY_PATH="`pwd`" ./js                                
js> print("Hello from a Pixel2!");
Hello from a Pixel2!

and

sailfish:/data/local/tmp $ LD_LIBRARY_PATH="`pwd`" ./js --baseline-eager test.js                          
Segmentation fault

It works on my personal Pixel2. It's still an opt build, so there are no symbols, but it's reproducible now.

There's no debugger, and the build artifact has no symbols. The best I've been able to do so far is reduce the testcase to the following:

// Run with --baseline-eager.
// These lines must be globally-scoped; it works if they're in a function.
gcparam("maxBytes", gcparam("gcBytes") + 1);
let k = /x/ [Symbol.replace]; // k is a function.
k + 1; // Just use k somehow, it doesn't matter.
k(); // Segfault.

Aha! It segfaults with --baseline-eager --no-ion.

Specifically, this variant segfaults with --no-ion:

// Run with --baseline-eager --no-ion.
// These lines must be globally-scoped; it works if they're in a function.
gcparam("maxBytes", gcparam("gcBytes") + 1);
let r = /x/;
let k = r [Symbol.replace]; // k is a function.
k.call(r); // Segfault.

Bad news: the crash only reproduces on opt builds. Debug builds pass, even on-device, both variants. Knowing that, I'll see if it can be reproduced on a SoftIron device with an opt build, since SoftIron has a debugger. Android seems to lack a native debugger and can't produce coredumps. I managed to get gdbserver set up on the phone, but I haven't been able to get the desktop client side working.

The last alternative is carefully-placed print statements to at least narrow the scope, but since I have to use Tryserver to build the binaries, each compilation takes about 45 minutes.

It does not reproduce on the SoftIron, even with an opt build.

I'm told that several people are following this saga, so I'll keep documenting things. The plan will be to eventually put this together into a wiki article so no one has to figure all this out again.

The official documentation for how to use GDB on Android is nonsense and a huge rabbit hole. The official instructions are to:

  1. Use a repo like https://github.com/innogames/android-ndk to download a pre-built binary named gdbserver and put that on your phone.
  2. Connect to the phone using adb and run adb shell setprop debug.debuggerd.wait_for_gdb true, because gdbserver doesn't handle processes that immediately crash.
  3. Follow the instructions at https://source.android.com/setup/build/downloading.html to download the 250GB Android source repository.
  4. Follow the instructions at https://source.android.com/devices/tech/debug/gdb to source envsetup.sh and lunch.
  5. Bing around for how to enable port-forwarding to your phone with lots of different answers.
  6. Theoretically now you can execute gdbclient -p $PORT and it will connect to the phone in a GDB session.

I failed around step 3 because I am on a laptop with a small SSD hard drive, and can't check out 250GB. I also can't use my desktop computer, because the Pixel2 only supports USB-C connections, whereas my desktop only supports USB2, and I don't have a cross-cable.

Anyway, here's another that isn't explained anywhere.

  1. On the phone, open Google Play and install the app "Termux".
  2. Open Termux and run pkg install gdb
  3. Run pkg install readline (or gdb will fail to start).
  4. gdb is now installed to /data/data/com.termux/files/usr/bin/gdb.

If you have a rooted phone, you're done, you can chmod 755 /data/data/com.termux and just run GDB. Unfortunately my phone is not rooted. If your phone isn't rooted, there's no way to do this through adb, so just accept that you're going to be debugging through gdb on a phone on-screen keyboard. Continuing if necessary.

You need to find somewhere to put the shell binary where the Termux user (in my case u0_a102) can read it. I tried /data/local/tmp/. In the adb shell, I ran chmod 775 /data/local/tmp/ (it starts as 771). Then Termux can see the file and view it, but even though it looks like the file is executable, permissions do not allow execution. So it has to go into /sdcard, but adb is disallowed from executing programs on /sdcard.

  1. In Termux, run termux-setup-storage. A pop-up will appear asking if you are willing to give Termux access to all of your photos, documents, files, etc. Although this is your personal phone and you'd really rather not, you have an impending deadline, so select "Accept."
  2. In Termux, copy the files to somewhere under $HOME. In my case the files were already in /data/local/tmp/ due to the above effort, so cp /data/local/tmp/* $HOME. If you didn't go through that step, the obvious place to put things that's available to both Termux and adb is /sdcard.
  3. In order to run the shell, you need to use $LD_LIBRARY_PATH. Termux takes over $LD_LIBRARY_PATH by default, setting it to /data/data/com.termux/files/usr/lib. So if you're in the same directory as the js executable and libmozglue.so, you can now execute the shell via LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$PWD" gdb ./js

And that works!

Well, no, it just looked like it works, because I was expecting a segfault.

In reality, the shell segfaults immediately in 0x0000007fb7676c76 from libmozglue.so.

I don't know what might be happening, but just before the crash, it prints warning: .dynamic section for "/data/data/com.termux/files/home/js" is not at the expected address (wrong library or version mismatch?).

Termux is however able to execute ./js outside of GDB; it only crashes on load within GDB.

Apparently you can just c continue past the libmozglue.so segfault and the shell will load just fine. OK.

The real crash info is here (saving mostly for my future reference). Note that this was retyped by hand, but I've tried to be careful.

0x00000055557daa24 in ?? ()

(gdb) x/9i $pc-16
   0x55557daa14:  mov x8, xzr
   0x55557daa18:  add x10, x10, #0x4ff
   0x55557daa1c:  mov w11, #0x5ee // #1518
   0x55557daa20:  str x10, [x9]
=> 0x55557daa24:  str w11, [x8]
   0x55557daa28:  bl  0x5555620540 <abort@plt>
   0x55557daa2c:  sub sp, sp, #0x40
   0x55557daa30:  stp x22, x21, [sp, #16]
   0x55557daa34:  stp x20, x19, [sp, #32]

(gdb) i r
x7  0xff7f7f7f7f7f7f7f
x8  0x0
x9  0x7fb7a66a68
x10 0x5555ff14ff
x11 0x5ee

(gdb) bt
#0  0x00000055557daa24 in ?? ()
#1  0x00000055558f3328 in ?? ()
#2  0x0000005555b8c40c in ?? ()
#3  0x0000005555b85fbc in ?? ()
#4  0x0000005555affdac in ?? ()
#5  0x0000007f76e28f5c in ?? ()
#6  0x0000007fb7216000 in ?? ()
Backtrace stopped: not enough register or memory available to unwind further

I don't know whether this is the right segfault, but I did at least verify via print() that it occurs after the script has begun execution. It looks like we set x8 to zero and then immediately dereference it.

Sorry to keep bugging you, Mike. Is there a way that I could have the build system statically link against libmozglue.so and libnss3.so to avoid this error with the dynamic linker on Android GDB? Also, is there a way to not strip the object files?

Flags: needinfo?(mh+mozilla)

(In reply to Sean Stangl [:sstangl] from comment #30)

Sorry to keep bugging you, Mike. Is there a way that I could have the build system statically link against libmozglue.so and libnss3.so to avoid this error with the dynamic linker on Android GDB?

Unfortunately no.

Also, is there a way to not strip the object files?

If you take the files from dist/bin they shouldn't be stripped.

Flags: needinfo?(mh+mozilla)

Some more information:

  1. The crash is in object code, not JIT code.
  2. The pattern of intentionally dereferencing nullptr in x8 and then calling <abort@plt> is common. It's the implementation of MOZ_REALLY_CRASH in mfbt/Assertions.h -- which means we're just hitting a MOZ_CRASH().

The objdump -d js output containing the crash location is here:

  2859ec:       f00041a1        adrp    x1, abc000 <ffi_closure_SYSV@@Base+0x115088>
  2859f0:       91083021        add     x1, x1, #0x20c
  2859f4:       910003e0        mov     x0, sp
  2859f8:       aa1303e2        mov     x2, x19
  2859fc:       94004ced        bl      298db0 <gettimeofday@plt+0x1cca40>
  285a00:       910003e0        mov     x0, sp
  285a04:       94004d0f        bl      298e40 <gettimeofday@plt+0x1ccad0>
  285a08:       d0005269        adrp    x9, cd3000 <_ZTVNSt6__ndk115basic_streambufIcNS_11char_traitsIcEEEE@@Base+0x60c50>
  285a0c:       f947a929        ldr     x9, [x9, #3920]
  285a10:       f00040aa        adrp    x10, a9c000 <ffi_closure_SYSV@@Base+0xf5088>
  285a14:       aa1f03e8        mov     x8, xzr
  285a18:       9113fd4a        add     x10, x10, #0x4ff
  285a1c:       5280bdcb        mov     w11, #0x5ee                     // #1518
  285a20:       f900012a        str     x10, [x9]
>>285a24:       b900010b        str     w11, [x8]
  285a28:       97f916c6        bl      cb540 <abort@plt>

The "#1518" is a line number, which is probably the most promising information we have to go on so far. Of course, that's probably the line number in a unified build, which isn't too helpful.

Now that we know we're hitting an opt MOZ_CRASH, the next steps are either one of:

  1. Disable unified builds and see if it still reproduces. If it does, then we'll get the line number on which it's crashing, and I can grep through each file to see which file contains a MOZ_CRASH() on that line. If we're lucky we might even be able to get away with MOZ_ReportCrash() in opt builds -- although it's possible that would change the binary too much.

  2. Figure out how to load symbols on Android GDB for opt builds. I looked through the "Job Details" on treeherder and didn't see any symbols for the JS shell, but maybe we can generate them.

First I'll make a Try build that does MOZ_ReportCrash() in opt.

Bingo! (Using the Try push https://treeherder.mozilla.org/#/jobs?repo=try&revision=08cc06cdfad7363ab2419e58d496f1ec7c49d3c6&selectedJob=231416771)

Assertion failure: [unhandlable oom] Could not allocate ObjectGroup in EnsureTrackPropertyTypes, at /builds/worker/workspace/build/src/js/src/vm/JSContext.cpp:1517
Hit MOZ_CRASH() at /builds/worker/workspace/build/src/js/src/vm/JSContext.cpp:1518

The line number corresponds to AutoEnterOOMUnsafeRegion::crash().

EnsureTrackPropertyTypes is a TypeInference method that's called by the Baseline compiler. That's why it reproduces with --no-ion, and also why it requires a JIT to reproduce.

The function that's hitting OOM is JSObject::getGroup(), in one of these AutoEnterOOMUnsafeRegion regions.

Jan, what did we decide happens with OOM now? At the last All-Hands I believe it was expressed that we are moving from handling OOM to just crashing on OOM Safari-style. Clearly the code in question (js::EnsureTrackPropertyTypes) makes no attempt to recover from the OOM it detects.

Is this segfault on Pixel2 devices therefore expected behavior after all?

Flags: needinfo?(jdemooij)

(In reply to Sean Stangl [:sstangl] from comment #35)

Is this segfault on Pixel2 devices therefore expected behavior after all?

We crash on OOM in places where recovering from OOM is hard/complicated.

bug1263857.js is marked as |jit-test| allow-oom; allow-unhandlable-oom

The allow-unhandlable-oom bit should take care of this but it works [0] by checking stderr contains 'Assertion failure: [unhandlable oom]'. So it seems what needs to happen here is making sure these messages are dumped to stderr when running jit-tests on these devices...

[0] https://searchfox.org/mozilla-central/rev/92d11a33250a8e368c8ca3e962e15ca67117f765/js/src/tests/lib/jittests.py#531-532

Flags: needinfo?(jdemooij)

(In reply to Jan de Mooij [:jandem] from comment #36)

The allow-unhandlable-oom bit should take care of this but it works [0] by checking stderr contains 'Assertion failure: [unhandlable oom]'. So it seems what needs to happen here is making sure these messages are dumped to stderr when running jit-tests on these devices...

Because of the slowness of Android devices, the tests are being run in opt builds, which turns off the output of such messages. Hm.

(In reply to Sean Stangl [:sstangl] from comment #37)

Because of the slowness of Android devices, the tests are being run in opt builds, which turns off the output of such messages. Hm.

Are you sure? We call MOZ_ReportAssertionFailure here:

https://searchfox.org/mozilla-central/rev/92d11a33250a8e368c8ca3e962e15ca67117f765/js/src/vm/JSContext.cpp#1521

And that dumps to stderr or Android's log file in all builds AFAICS:

https://searchfox.org/mozilla-central/rev/92d11a33250a8e368c8ca3e962e15ca67117f765/mfbt/Assertions.h#157-171

Attached file Android must fprintf() on MOZ_CRASH() (obsolete) —

Android debugging uses __android_log_print(), which outputs to the Android logger.
Some test runners (notably jit-tests) require debug output on stderr.
This patch causes output to both stderr and the Android logger.

Flags: needinfo?(sdetar)

Glandium rejected the patch that outputs to stderr.

Given that we can't output to stderr, the fix for this issue is then to teach the jit-test harness to read the Android log. That is a much larger patch and error-prone.

This bug is not a real bug, it is a false positive. We have a deadline to turn on IonMonkey in a few days, and this non-issue is the final blocker. Therefore I propose that we just punt on this issue by disabling the test, and then once the hard deadline is passed, I'll work on the Python harness as follow-up work.

Disable auto-regress/bug1263857.js, leaving it for follow-up work.

(In reply to Sean Stangl [:sstangl] from comment #40)

This bug is not a real bug, it is a false positive. We have a deadline to turn on IonMonkey in a few days, and this non-issue is the final blocker.

I'll remove the [arm64:m2] whiteboard tag since this bug is not a blocker for shipping ARM64 Ion.

Whiteboard: [arm64:m2][stockwell unknown] → [stockwell unknown]

(In reply to Sean Stangl [:sstangl] from comment #40)

Therefore I propose that we just punt on this issue by disabling the test, and then once the hard deadline is passed, I'll work on the Python harness as follow-up work.

I'm a bit worried this will be a source of intermittents and a footgun when adding new tests. Please file a follow-up bug marked as tracking-for-67.

Flags: needinfo?(sstangl)

(In reply to Chris Peterson [:cpeterson] from comment #42)

(In reply to Sean Stangl [:sstangl] from comment #40)

This bug is not a real bug, it is a false positive. We have a deadline to turn on IonMonkey in a few days, and this non-issue is the final blocker.

I'll remove the [arm64:m2] whiteboard tag since this bug is not a blocker for shipping ARM64 Ion.

My understanding is that it is a blocker, as we would not ship ARM64 if we cannot turn the test suite on.
Then whether the bug describe here is real or not is another story.

(In reply to Jan de Mooij [:jandem] from comment #43)

I'm a bit worried this will be a source of intermittents and a footgun when adding new tests.

32-bit Android has the same behavior, and we haven't noticed until now. So I suspect we will not notice in practice.

Please file a follow-up bug marked as tracking-for-67.

Yep, that was the plan in Comment 40.

(In reply to Chris Peterson [:cpeterson] from comment #42)

I'll remove the [arm64:m2] whiteboard tag since this bug is not a blocker for shipping ARM64 Ion.

Although there is no bug in Ion, it's still a blocker, because we need the test to pass. The bug is in the test suite harness.

Flags: needinfo?(sstangl)
Blocks: 1532654
Whiteboard: [stockwell unknown] → [arm64:m2] [stockwell unknown]

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

Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox67: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
Assignee: nobody → sstangl
Attachment #9048183 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: