Open matthewdunbar opened 2 weeks ago
We also noted that it this works successfully on:
Whatever happened in Chrome 126 on ARM has caused some sort of issue. Something with the Javascript instruction set that uPickle creates and then when that instruction gets JIT'd on ARM it causes a bug that spikes the process in chrome to 100% and deadlocks that chrome process.
As Matthew noted, this is hits on serializing anything, so I'd expect this to come up pretty quickly for uPickle users as Chrome 126 adoption rate goes up.
This simple app pegs the chrome process on this tab out at 99% and deadlocks (never completes). Only happens on Chrome 126 on ARM.
Can't you submit the Javascript/repo to the Chrome (assuming you are not running through GCC)?
We are already in process! Hopefully others who hit this won't open a ticket on uPickle for this. It's a big impact though - serializing even a simple string with uPickle on chrome 126 causes the break.
We've figured out a workaround to prevent this issue. For now we forked upickle, but here's a PR if you're interested in it: https://github.com/com-lihaoyi/upickle/pull/590
When running Chrome v126 on ARM devices, calling
upickle.default.write(...)
multiple times eventually causes Chrome to freeze. We verified this is affecting both Android phones and M1 based Macs (and likely other ARM based devices)I have created a minimal reproducible example here with instructions to replicate the bug: https://github.com/matthewdunbar/scalajs-chrome-bug-example
We suspect this is a bug in Chrome since our code runs correctly on v125 but starts having issues on v126. Does anyone have any thoughts on how to resolve this?