这是一个创建于 240 天前的主题，其中的信息可能已经有所发展或是发生改变。
1.可能无法识别外接显示器的 USB 集线器。
2.用户无法打开或者通过验证某些音乐应用，这些应用中包含版权保护的 Audio Unit 插件。
3.包含 Java 代码的某些应用程序会意外退出
24 条回复 • 2024-04-16 13:48:07 +08:00
 |
1
Goooooos 240 天前
这是 bugfix 吧
|
 |
2
pwelyn 240 天前
已更新
|
 |
4
2kCS5c0b0ITXE5k2 240 天前  3
之前说 Java 滥用特性的说两句把.
|
 |
5
jdjingdian 240 天前
确定修复了吗，有没有大佬说一下，现在还会闪退吗
|
 |
7
mnsw 240 天前
@jdjingdian #5 试了下，应该是修复了。
|
 |
8
daveh 240 天前 via iPhone 4
@emeab #4 滥用信号机制的代码由于性能原因，OpenJDK 主线已经偷偷删除，性能提升了 12% ，JDK23 已经默认带了；一些厂商如 JetBrains 回合相关代码到 JDK17 ，解决 JB 全家桶在 M1-M3 上异常问题。
OpenJDK 自己也提了几个 issue 去解决 signal 机制滥用问题，感兴趣去看看 bugs.openjdk.org 。 不过 Apple 也帮擦屁股，就像以前给 WeChat 擦屁股： https://cloud.tencent.com/developer/news/761277 |
 |
9
pbo747253BLjI60O 240 天前
老师能不能帮忙看看 14.4.1 更新后，「系统设置」-「通用」-「语言与地区」的「列表排列顺序」里面有没有「中文 (简体中文排序 - GB2312)」
|
|
11
pbo747253BLjI60O 240 天前
@ihwbunny 灰藏感谢！
|
 |
12
giganet 240 天前 1
14 真是问题多多啊，幸亏没升...
|
 |
13
bjfane 240 天前
webstorm 崩过一次，等升 14.4.1 再观察观察
|
 |
14
ShadowPower 240 天前
@daveh 我根本享受不到这些，只有忍受每天不定时崩溃……
|
|
15
ShadowPower 240 天前 1
@daveh 还有，如果是苹果故意这么做的，那给我的印象就更糟糕了，比工程师改代码测试忘记改回来还合并进去了的情况糟糕。
这意味着，当苹果想更改系统行为的时候，有这些选择： 1. 发布公告说明 macOS 即将发生重大改变，可能会对应用兼容性产生影响。在公告里说明为什么要作出这项更改，有什么好处，让各大开发商尽快完成适配工作（或选择放弃兼容 macOS ）。 2. 偷偷发布正式版更新，直接对最终消费者进行惩罚，通过引发严重故障让他们来倒逼软件开发商适配。像 Java 这种有人买了商业支持，客户有要求，不能不做。 苹果觉得 2 比 1 好。 |
 |
16
lingxiaoli 240 天前 1
@bjfane webstorm 更新了
|
|
17
bjfane 240 天前
@lingxiaoli 还真是，之前是 3.4 ，3.6 还专门说 crash 的问题，更新了，2024 等等再更
""" There are reports that the latest update to macOS (Sonoma 14.4) on Apple silicon-based machines is causing crashes on certain software running on the JVM. Apple is already aware of the problem """ |
|
18
daveh 239 天前 via iPhone
@ShadowPower #15 你更新到 JDK23 就能享受到，JB 全家桶更新到 JBR17 最新版本就不会崩溃了。
不清楚 Apple 什么原因修改，但是从原理上讲安全性是提高了，M1-M3 上进程某块区域不允许随便读了，可以保护敏感信息。一些恶意程序、poc 程序最喜欢在进程全地址空间扫描，触发提权漏洞，反正读到无效地址有 signal 兜底，处理好后可以继续。但在 14.4 行不通了，读到保护地址进程就挂，没机会继续扫描了。不清楚 14.4.1 改动什么了，如果是简单还原，安全性又降回去了。 |
|
19
ShadowPower 239 天前 1
@daveh
公司的项目并不会崩溃，开发工具（例如 DBeaver ）之类的偶尔会崩溃。而且不是升级 JDK 就能解决，大多数软件只兼容 JDK 17 ，兼容不同版本的 JDK 得改代码适配。而且非 LTS 版本能用的第三方库不全，大家都不会花时间精力在这种版本上。 这种事情都是说起来轻松，实际做起来，还不如直接抛弃 macOS 改用 Windows ，省下的时间活都干完了。 这和安全也没有什么关系，我没见过有任何有信服力的说法能证明这个改动提升了安全性，只见过果粉用这个说法来给苹果的行为辩护。 |
|
20
daveh 239 天前 via iPhone
@ShadowPower #19 你把前面我说的看懂再来回答，不要直接上来就暴露自己的无知，不要连果粉都不如。
大多数漏洞利用程序，比如能跑越狱提权的，都可能有前面说的运行模式，不断探测可利用的地址空间，同时要防止访问无效地址空间自己挂了。 现 Apple 改为乱访问保护地址直接挂进程，漏洞越狱程序都跑不起来，这还不是提高安全性？漏洞不一定能及时修，修了用户也不一定及时升级，如果漏洞程序跑不起来，阻止了漏洞利用程序的运行机制，即使用户不升级也没关系，黑客只能看着漏洞干瞪眼。 另外 JDK 也有一定兼容性，换高版本一般也可以随便跑，你说 DBeaver 崩溃，建议你换 JBR17 去跑一下再来说话。 |
|
21
ShadowPower 239 天前 1
@daveh
我确实看不懂，得向你请教一下 > 一些恶意程序、poc 程序最喜欢在进程全地址空间扫描 能不能具体说明是哪个恶意程序或者 poc 程序，利用的是哪个漏洞。如果只是漫无目的地扫描，那么它接下来该做什么？ > 触发提权漏洞 看来范围更小了，能更详细一些吗？ 现代的操作系统进程的地址空间都是虚拟地址，程序获取自己申请的内存和加载的动态链接库的内存地址不需要通过一个个扫描地址的方式来探测，一般都可以通过操作系统提供的接口来得到。 为什么会存在需要全地址扫描才能得知的内存地址，而且这个应用程序居然还能有权访问（即不会触发 SIGSEGV 、SIGBUS ，因此程序能够通过是否收到信号的方式来找到它）。我对 macOS 的内核完全不了解，如果这是 macOS 特有机制，可以简单介绍一下，或者给我相关信息供我检索吗？ 你的说法听起来也适用于 Linux 。为何从未听说过有云服务厂商担心这个问题，尤其是提供 Docker 容器服务、云函数等功能的厂商 |
|
22
ShadowPower 239 天前
@daveh 对了，至于换 JBR17 跑一下这个事情，因为我已经第一时间升级到 14.4.1 了，所以已经没有必要测了。
|
 |
23
icebow 238 天前
更新完之后，鼠标滚轮失效了， 鼠标是 anywhere 2s
|
 |
24
mackxu 219 天前
webstorm 解决办法 -Dsun.java2d.metal=false
in Help | Edit Custom VM Options and restart the IDE |
Select Language