@felixlong
测试了一下，访问 null 也真的会导致 sigkill （去掉 pthread_jit_write_protect_np(0)这句就 SIGSEGV)
#include <pthread.h>

int main() {
pthread_jit_write_protect_np(0);
return *((int *)NULL);
}

@Jirajine 首先这不是 ub ，是标准允许的做法，其次虽然可能不是 null 的那个问题，但另一个 guard page 更是这个 api 的原本目的，不然为何提供 mmap PROT NONE 这个选项

@felixlong 上面我发了复现代码了，可能确实不是 0 页面的访问，但 mmap 只是去申请了一个权限为 0 的页面，然后去访问，正常情况只会触发 sigbus ，但 14.4 结合 write protection 后会直接 sigkill
这里不涉及任何真正的 jit 只是单纯的开一个页面当做 guard page

@DigitalG 只是不影响用 graalvm 这样直接 aot 的，其他 java 程序全都受到影响

找到了一个问题复现的代码
#include <stdio.h>
#include <sys/mman.h>
#include <pthread.h>

int main() {
pthread_jit_write_protect_np(0);

char* mem = (char*)mmap(0, 16 * 1024, 0, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0);
fprintf(stderr, "addr = %p\n", mem);

char value = *mem;
fprintf(stderr, "value = %c\n", value);

return 0;
}
，在之前版本里是 sigbus ，可以捕获，14.4 就直接 sigkill 了
原来这个 write 模式是指这玩意

@iseki 啊，写错了，是要有 jit ，还得刚好处于 write 的状态触发

我升级 14.4 后 c 口一线直连扩展屏幕，休眠的时候屏幕变粉色然后死机，大概可能也有关系

@felixlong 目前据我所知只有 java 在广泛使用这个技巧，其他 jit 都没这么做
不过数组越界肯定不会用这个方法，总不能一个数组刚好吃一个 4k 页面(apple silicon 好像是 16k)，然后上下两侧摆 guard page ，这也太奢侈了
至于空指针，支持 jit 的语言里有空指针暴露给用户的就挺少的了 js 肯定不是，go 和 net 据我所知也没人说有做类似优化

@lslqtz 我怀疑可能是有什么延迟上的差异导致泄露信息🤔

@tanrenye 触发条件看脸，得刚好在 jit 的时候触发被 jit 优化的空异常处理代码

@meloyang05 我的个人猜测应该是苹果发现了什么影响安全性的严重 bug ，可能是已经有在野利用了

@rainbowmolly 以前的说法是，通过检测 segsigv 的方式，在 happy path (也就是没异常)的时候性能比较好，甚至于在特定情况（比如 jit 发现某个参数几乎没有 null 过）省略用户主动写的 null 判断更快

补充一下，这个需要刚好在 jit 运行的时候（也就是线程正处于 write 的模式）才会触发的 sigkill 其他时候依然是正常流程，因此 grallvm 等直接生成 binary 的不受影响

可能是因为有多个 webview 同时存在导致的问题，试试这个项目

https://github.com/didimoo/AndroidLocalStorage

setDomStorageEnabled 开了吗

windows 的 ssh 运行在非交互式会话里，相当于是服务，没办法启动含有 gui 的进程

看了一下，好像是字母全部被偏移了 2
f=(x)=>x.split('').map(c => String.fromCharCode(c.charCodeAt(0)+2)).join('')
f('rcpkgl_j') === 'terminal'
我感觉可能大概是字体解析出了问题？？

听起来是不让用 webview ，但 cordova 核心就是 webview 吧。。

https://bugs.ruby-lang.org/issues/14635
看了一下关联的 issue ，这个可能和浮点数通常的问题有些不一样