Switchyomega: 自动代理时 Chrome 卡顿、死机、崩溃等情况 | Chrome stalls/unresponsive/crashes when using Auto Switch

Created on 4 Jul 2016  ·  36Comments  ·  Source: FelisCatus/SwitchyOmega

所有标签页都卡住,只有重启chrome可以解决


The following comments are added by @FelisCatus:

tl;dr This is an issue with Chromium proxy resolver and fixed in Chrome 57+. Please install the latest version of Chrome. The issue is unrelated to SwitchyOmega.

以下内容为 @FelisCatus 追加:

这个问题是 Chromium 代理解析进程导致的, Chrome 57 已经修复。请安装最新版 Chrome. 此问题与 SwitchyOmega 无关。

Most helpful comment

Good news everyone:
image

Chrome 57 released.
image

All 36 comments

不妨试试看多等一会,测试下是无限卡住还是只是卡很长一段时间。


以下内容为 @FelisCatus 追加:

症状:使用自动切换时, Chrome 可能会卡在解析代理服务器……状态,无响应或者崩溃。 Chrome 进程会使用大量内存。有时整个系统都会受此影响。

表面原因: Chrome 发生内存泄漏或者其他突发占用大量内存的情况。

深层原因:已经确认是 Chrome 方面的代理解析进程问题,已经在代码中修复。安装 Chrome 57 应该可以解决。

之前猜测是以下三种原因之一:

  • Chrome 的代理解析进程问题,对于其他 PAC 脚本也会发生,并非 SwitchyOmega 问题。
  • SwitchyOmega 生成的 PAC 脚本中有内存泄漏。

    • 我个人觉得不是,因为生成脚本的逻辑没有改过,而之前版本中并未有此问题。

  • SwitchyOmega 后台进程内存泄漏。这可能是 SwitchyOmega 的代码问题也可能是 Chrome 问题。

    • 很难诊断。如果有条件,欢迎提供 Shift+Esc 的截图或者 SwitchyOmega background.html的 Heap Snapshot.

    • 根据这个 Issue 的说明,直接使用命令行应用 PAC 也可以复现,不需要安装 SwitchyOmega. 基本可以排除此可能。

请点右侧 Subscribe 按钮关注此 Issue 来获取更新。


The following comments are added by @FelisCatus:

Symptom: When Auto Switch is applied, Chrome could hog on resolving proxy..., go unresponsive or crash. A lot of memory may be used by the Chrome process. This sometimes can affect the whole system.

Reason: Chrome eats a lot of memory in a short time, or has a memory leak.

Cause: Chrome's proxy resolver process has memory leaks. The issue has been confirmed and fixed and a fix is landed in Chrome 57.

Originally, it was determined to be caused one of the three reasons below:

  • A problem with Chrome's proxy resolving process. If so, this could also happen to other PAC scripts and is unrelated to SwitchyOmega.

    • Someone opened an issue at Chromium. Still waiting for reply from Chromium developers.

  • The PAC script generated by SwitchyOmega has a memory leak.

    • I don't think that's quite possible, because the generator logic hasn't been changed recently. There were no such reports in earlier versions.

  • Memory leak happens in the SwitchyOmega background process. This could be either SwitchyOmega's fault or Chrome's fault.

    • This is hard to tell. Screenshots of Chrome's task manager (Shift+Esc) or Heap Snapshot of SwitchyOmega's background.html are welcome.

    • According to this issue, the same thing happens when you apply the PAC script directly using command-line flags. Therefore the background process is very unlikely to be involved in this.

Please subscribe to this issue for updates.

请在选项的自动切换模式中,点击导出 PAC 脚本,并将结果上传到这里以便分析问题。

已测试,很长一段时间,大概1分钟左右会好,稍后上传

我的也是一样,排查了好久才发现是这插件的问题
windows10 14379
chrome://extensions/?id=padekgcemlokbadohgkifijomclgjgif 2.3.19
chrome 51 x64
会突然卡住,不管有多少标签页,一个chrome进程内存飙升至2G+

@fengjch127 的规则列表中,并不是规则列表文本,而是 HTML 的一个网页,请检查。规则列表正常后再试。

@klzsysy 看上去一切正常,生成的 PAC 文件和之前是完全一样的,不存在任何问题。然而最近 Chrome 51 后可能 PAC 处理有一些变化,只要 PAC 文件大一点很容易占用大量资源,这不是 SwitchyOmega 能控制的。我建议降级 Chrome 或者尝试 Chrome Beta/Dev/Canary 等更新的版本,看是否能解决问题。 @fengjch127 如果问题解决后也还是这个情况,也同理。

或者如果机器性能有限,可以尝试不要使用太大的规则列表,而是尽量使用自定义规则,或者使用白名单的方式自动切换。

顺便,请大家都检查下chrome://flags/#v8-pac-mojo-out-of-process的选项。如果是开启的话可以尝试关闭(将此 flag 设置为 Disabled ),应该可以解决。

有人在 https://bugs.chromium.org/p/chromium/issues/detail?id=639217 汇报了这个问题,大家可以去关注那边的进展。目前有人评论说脚本没有明显的泄漏(也就是说不是 SwitchyOmega 的生成引擎问题)。

在顶楼更新了目前的状况总结。请点右侧 Subscribe 按钮关注此 Issue 来获取更新。

I've summarized all information that we know and updated the original post. Please subscribe to this issue for further updates.

Someone at the Chromium project suggests that we should run the PAC script in browser and profile it using Chrome Developer Tools. See the original comment on how you could do it. Unfortunately, I don't have time of doing all these stuff right now. So if any of you feels like to do it, please do submit your result at that issue (but NOT HERE) to move the issue forward.

今天刚刚更新Chromium后,
开启#v8-pac-mojo-out-of-process, 测试没有内存泄漏。
Chromium Version 53.0.2785.101

我也经常出现此问题,应该是chrome本身造成的。短时间内存占用飚升,造成整个系统无法操作。需要的等到一分钟左右才勉强打开任务管理器结束掉出现的进程恢复。无法访问网络时只打开一个路由器页面也会发生。我根本没开代理进程,也会发生,从48版本开始连续几个版本都发生过。我估计这种隐藏的BUG一直拖着吧,一般用户很难发现和反馈的。

Win10 Chorme :54.0.2840.99 m (64-bit)
Proxy SwitchyOmega:2.3.21

关闭V8 代理解析工具之后依旧有此问题,发现在autoproxy新添加GFWlist(https://raw.githubusercontent.com/gfwlist/gfwlist/master/gfwlist.txt)
规则后就会出现这个现象,特别是在网页图片内容比较多的时候容易出现, 期间CPU,内存,SSD硬盘读写全部飙升至100%,卡顿持续5-7秒。

@yueyingjuesha +1,依然存在此问题,CPU无明显使用,内存存在泄露,磁盘读写100%

@FelisCatus
System: Windows 10
Chrome: 54.0.2840.87 m (64-bit)
情景模式: 自动代理
规则: GFWlist

图

感谢提供数据,目前结论不变,仍然认为是 Chrome 问题。建议继续前往 https://bugs.chromium.org/p/chromium/issues/detail?id=639217 反馈并提交内存占用报告。

Windows 更新到 Chrome 55 之后可以用自动模式,Ubuntu 上 55 版的 Chrome/Chromium 还是不能用,可以在系统设置 Network-> Proxy 中设置自动模式,用 pac 文件。

同样遇到这个问题:Windows10 1607,chrome auto switch + GFWlist,出现硬盘100%读写,系统卡死,超过30分钟,只能热启动。
估计是内存泄漏,导致硬盘交换文件pagefile过量读写导致系统死锁。

将GFWlist pac模式去掉后,故障消失。

看了omega生成的pac脚本,基本都是if(/(?:^|\.)nottinghampost\.com$/.test(host))return"+GFWed";的语句的堆叠;
而shadowsocks-windows的pac生成的规则是Adblock的方式,利用了轻量字典来存储规则,匹配时候使用了字典的索引,这样的效率更高;

我之前一直使用shadowsocks的本地处理pac,只是添加地址不大方便; 换到Omega插件使用后,每天都几次被内存泄露弄得死机。

之前PAC脚本性能上都没出过什么问题,内存占用也是好的……从 @pentie 的观察看来,感觉这次 V8 的问题可能与正则表达式编译有关,去掉正则也许能好一些?

感觉把生成器重新写一遍会是个大工程呢,以我目前的精力……大概是不行的吧。

目前已经确认是 Chrome 方面的代理解析进程问题,已经在代码中修复。预计 M57 发布。

It is confirmed to be a problem with Chrome's proxy resolver process. The issue has been fixed in chromium and a fix is expected to land at M57.

楼上中文M57,英文M51。哈哈

The fix should be landed in Chrome Beta 57 right now. Please try it out to see whether the problem is fixed.
(EDIT: Typo. The version number introducing the fix should be 57, not 51.)

Chrome 57 Beta 版本已经发布,应该可以解决此问题。如果各位受此困扰,可以去安装Beta版来测试下。

刚更新到Chrome 56,依旧有这个问题。持续关注中

@catscarlet 根据 Chromium 那边的记录,修复的代码应该只合并到了 57. 如果有时间的话麻烦试一下 Beta 版吧。

还是等正式版吧。Chrome的问题其实挺多的,前几天写脚本写错了,死循环往一个数组里不停填变量,一个原本只占40M内存的页面瞬间上2G,Chrome也不对这种情况限制一下。
有点开始怀念32bit的Chrome了,至少超了2G自己会崩,而不是一直把系统吃到死机

Good news everyone:
image

Chrome 57 released.
image

似乎Chrome 57正式版仍然存在此问题,不过这是我个人的观察,有待更多报告的反馈。

所以可能还是没有根治问题?

似乎Chrome 57正式版仍然存在此问题,不过这是我个人的观察,有待更多报告的反馈。

我在 chrome 57用了两天,没出现问题;

只是升级57后第一次启动插件,因为规则列表过期,而更新地址处空白,任务管理器显示V8占用CPU50%+,浏览器什么网页都无法显示;先改成纯代理,更新了列表,就正常了。

57之前的版本,每天会出现至少2次内存暴涨导致的死机。

升级到57后持续用了两周,一次问题都没出现。

应该修复了。

版本61.0
依然存在 V8 代理解析工具 占用大量内存的情况

ArchLinux, chromium 62.0.3202.62-1
Problem still exists.

i.e. No v8-pac-mojo-out-of-process in chrome://flags/.

Google Chrome | 62.0.3202.94 (正式版本) (64 位)

V8代理解析工具依然占用大量内容。如果超过24小时不重启浏览器,该进程内存直接飙升到2G+。

我的 Version 62.0.3202.94 (Official Build) (64-bit) archlinux下,v8 proxy resolver 仍然占用600M内存,重加载 proxy switchy omega 后恢复。

Was this page helpful?
0 / 5 - 0 ratings