V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  codehz  ›  全部回复第 10 页 / 共 133 页
回复总数  2650
1 ... 6  7  8  9  10  11  12  13  14  15 ... 133  
@houshuu 但其实没什么用,这次的问题是随机概率触发的,上面有人就没触发过。。。
合理的方案是在不破坏互操作性的前提下(例如不能出现旧版本无法打开项目的情况),进行灰度升级
全屏实现其实挺复杂的(因为跳过了窗口混合的过程),对老游戏可能可以 dxhook 一下,但虚拟机的估计没那么好做。。
除非 vmware 用的是无缝窗口模式,那种也许可以骗过去。。。
@daveh
这个修改也只是另一个性能优化 https://bugs.openjdk.org/browse/JDK-8283326

SafeFetch is important - mostly when writing hs-err reports, but it is also used in low level utility functions like `os::print_hex_dump()` and `os::is_readable_pointer()`. It is also used (JDK-8282306) as part of call stack printing. At the moment it is implemented via dynamically generated stub routines
@daveh 没错是改成 static 了,但还是用信号的啊 https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/safefetch_static_posix.cpp
只不过把 safefetch 本身的代码用汇编写成直接一个 mov 或者 ldr
https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/bsd_aarch64/safefetch_bsd_aarch64.S
不是很懂为啥要杠这一点
@daveh https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/safefetch_sigjmp.cpp 在 posix 下的实现就是 sigsetjmp 保存跳转地址,然后在异常处理代码里检测 SIGSEGV 和 SIGBUS 来跳转到返回 false 的分支
@daveh SafeFetch 整个函数的意义就是访问非法地址的时候能检测到结果,你是不明白这个 fetch 的含义吗。。。
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/safefetch.hpp#L31-L32
@lslqtz 你看的是 https://developer.apple.com/documentation/xcode/investigating-memory-access-crashes 这个吧,问题是这并不是同一个问题,它是“调查因内存问题而崩溃的方法”
@daveh 我不知道你是在哪里得来的这个结论
https://bugs.java.com/bugdatabase/view_bug?bug_id=8320317
是这个吗?确实删除了一个对 SafeFetch 的调用,可问题是是在这里吗,后文不也提及了
JDK-8320317 removes this specific call to SafeFetch. We could probably still still hit similar issues with other calls to SafeFetch
@daveh 此外 pthread_jit_write_protect_np 是只有 macOS 给 apple sillicon 提供的功能,solaris 根本就没这个 api ,何来的十几年的垃圾代码
@daveh 这个问题就是苹果的错误,就算 JRE 触发是一个意外,也不能改变它就是苹果的错误,因为这个行为( pthread_jit_write_protect_np 0 的时候 SIGSEGV 和 SIGBUS 变为 SIGKILL )没有任何文档提及,也没在更新日志里包含,乃至专门介绍安全性的更新内容( https://support.apple.com/zh-cn/HT214084 )的文档也没有说有这个变更
OpenJRE 自己去 workaround 这个问题,和苹果意外搞出的错误没有任何关系
@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 的状态触发
236 天前
回复了 kevvvinyao 创建的主题 macOS macOS sonoma 14.4 显示器扩展坞失灵
我升级 14.4 后 c 口一线直连扩展屏幕,休眠的时候屏幕变粉色然后死机,大概可能也有关系
@felixlong 目前据我所知只有 java 在广泛使用这个技巧,其他 jit 都没这么做
不过数组越界肯定不会用这个方法,总不能一个数组刚好吃一个 4k 页面(apple silicon 好像是 16k),然后上下两侧摆 guard page ,这也太奢侈了
至于空指针,支持 jit 的语言里有空指针暴露给用户的就挺少的了 js 肯定不是,go 和 net 据我所知也没人说有做类似优化
@lslqtz 我怀疑可能是有什么延迟上的差异导致泄露信息🤔
@tanrenye 触发条件看脸,得刚好在 jit 的时候触发被 jit 优化的空异常处理代码
1 ... 6  7  8  9  10  11  12  13  14  15 ... 133  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2721 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 23ms · UTC 14:41 · PVG 22:41 · LAX 06:41 · JFK 09:41
Developed with CodeLauncher
♥ Do have faith in what you're doing.