❌

普通视图

发现新文章，点击刷新页面。
昨天以前治部少辅

Emscripten Fetch 接口的一个潜在内存泄漏问题

✇治部少辅
作者 治部少辅
2025年5月7日 18:04

近日发现了一个非常刁钻的可能引起基于 Emscripten 编译的 WASM 程序内存泄漏的问题。Emscripten 工具链提供了 Fetch 功能模块，这个模块允许我们调用浏览器的 fetch 接口来进行网络访问。

一个使用 fetch 接口的简单例子是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#include <stdio.h>
#include <string.h>
#include <emscripten/fetch.h>

void downloadSucceeded(emscripten_fetch_t *fetch) {
  printf("Finished downloading %llu bytes from URL %s.\n", fetch->numBytes, fetch->url);
  // The data is now available at fetch->data[0] through fetch->data[fetch->numBytes-1];
  emscripten_fetch_close(fetch); // Free data associated with the fetch.
}

void downloadFailed(emscripten_fetch_t *fetch) {
  printf("Downloading %s failed, HTTP failure status code: %d.\n", fetch->url, fetch->status);
  emscripten_fetch_close(fetch); // Also free data on failure.
}

int main() {
  emscripten_fetch_attr_t attr;
  emscripten_fetch_attr_init(&attr);
  strcpy(attr.requestMethod, "GET");
  attr.attributes = EMSCRIPTEN_FETCH_LOAD_TO_MEMORY;
  attr.onsuccess = downloadSucceeded;
  attr.onerror = downloadFailed;
  emscripten_fetch(&attr, "myfile.dat");
}

Fetch API 提供了一些比较高阶的功能，一种一个比较重要的功能是，他可以将下载的内容缓存到 IndexDB 中，这个缓存机制能够突破浏览器自身的缓存大小的限制（一般超过 50MB 的文件浏览器的自动缓存机制会拒绝缓存）。但是这个缓存机制会导致内存泄漏。

1 泄漏产生的过程

在开头的例子中，我们需要再 onerror 和 onsuccess 回调中调用 emscripten_fetch_close 接口来关闭 fetch 指针代表的请求。在关闭过程中，fetch 使用的数据缓存区将会被回收。这个过程如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
EMSCRIPTEN_RESULT emscripten_fetch_close(emscripten_fetch_t* fetch) {
  if (!fetch) {
    return EMSCRIPTEN_RESULT_SUCCESS; // Closing null pointer is ok, same as with free().
  }

  // This function frees the fetch pointer so that it is invalid to access it anymore.
  // Use a few key fields as an integrity check that we are being passed a good pointer to a valid
  // fetch structure, which has not been yet closed. (double close is an error)
  if (fetch->id == 0 || fetch->readyState > STATE_MAX) {
    return EMSCRIPTEN_RESULT_INVALID_PARAM;
  }

  // This fetch is aborted. Call the error handler if the fetch was still in progress and was
  // canceled in flight.
  if (fetch->readyState != STATE_DONE && fetch->__attributes.onerror) {
    fetch->status = (unsigned short)-1;
    strcpy(fetch->statusText, "aborted with emscripten_fetch_close()");
    fetch->__attributes.onerror(fetch);
  }

  fetch_free(fetch);
  return EMSCRIPTEN_RESULT_SUCCESS;
}

可以看到，回收并非总会发生， emscripten_fetch_close 函数会对 fetch 的部分状态进行检查，如果检查失败，则会返回一个 EMSCRIPTEN_RESULT_INVALID_PARAM 的错误码，并且不会执行后续的清理过程(`fetch_free)。被检查的两属性中，fetch->id 是我们需要关注的对象。fetch->id 这个属性作为 fetch 的唯一标识符，是用来建立起 C++ 端的请求对象和 JS 端的请求对象的映射的。id 的值在 JS 端分配。查看源码中的 Fetch.js 文件，

1
2
3
4
5
6
7
8
9
10
11
12
function fetchXHR(fetch, onsuccess, onerror, onprogress, onreadystatechange) {
  // ...

  var id = Fetch.xhrs.allocate(xhr);
  #if FETCH_DEBUG
    dbg(`fetch: id=${id}`);
  #endif
    {{{ makeSetValue('fetch', C_STRUCTS.emscripten_fetch_t.id, 'id', 'u32') }}};

  // ...

}

这是唯一的一处 id 复制。这段代码位于 fetchXHR 函数中，这意味着只有发起了 XHR 请求时，id 才会被分配。那么，如果缓存存在呢？这时不会调用 fetchXHR 函数（而是调用 fetchLoadCachedData 函数）。这意味着回调函数中我们试图调用 emscripten_fetch_close 函数来关闭请求并回收资源时，这个回收过程无法进行，这导致了内存泄漏。

2 怎么解决这个问题

要解决这个问题我们只需要强行让 fetch->id == 0 的检查无法通过即可，我们可以在 emscripten_fetch_close 调用前，强行设置 fetch->id 为一个非零值。那么什么值合适呢？如果我们取值和已有的请求的 id 相同，那么 emscripten_fetch_close 可能将那个请求关闭。研究 id 分配的过程（即 Fetch.xhrs.allocate 的实现）

1
2
3
4
5
6
// libcore.js
allocate(handle) {
  var id = this.freelist.pop() || this.allocated.length;
  this.allocated[id] = handle;
  return id;
}

可以看到，id 是顺序分配的，且使用过的 id 会被回收使用（freelist）。因此我们可以设置一个较大的值，只要同一时间最大的并发请求数量不超过这个值，那就是安全的。我一般选择设置为 0xffff。 那么，正确的关闭请求的方式是：

1
2
3
4
if (fetch->id == 0) {
  fetch->id = 0xffff;
}
emscripten_fetch_close(fetch);

在 VPN 场景下的跨子网通信防火墙配置方法

✇治部少辅
作者 治部少辅
2024年10月24日 10:38

这篇文章介绍手搓 Site-to-Site 组网的方法。

1 场景简述

假设我们有两个机器 A 与 B，其中 A 和 B 在各自的局域网中的网段分别是 192.168.2.0/24 和 192.168.3.0/24。A 和 B 都接入了一个 VPN 网络，其内网地址是 10.0.0.0/16。那么，如何让 A 访问 B 所在局域网内的另一台机器 C 呢？注意 C 是没有接入到 VPN 私有网络的。一个办法是直接让 C 也接入到 VPN 网络中，但是如果 B 的局域网中有众多设备需要被 A 访问时，将这些节点都加入 VPN 网络配置会非常麻烦。在一些场景下，VPN 的连接数量有限制（例如 Zerotier）。因此我们需要新的方案。这篇文章我们介绍通过巧妙地配置路由表和防火墙来实现。

我们假定 A 的地址是 192.168.2.2/24 和 10.0.0.2/16，B的地址是 192.168.3.2/24 和 10.0.0.3/16，C 的地址是 192.168.3.3/24。我们这里介绍的是让 A 访问 B 所在的子网。反过来让 B访问 A的子网的设置方法是类似的。进行双向设置以后就可以实现完整的 Site-to-Site 组网。这里我们假设 A 和 B 都安装了 Ubuntu 操作系统。

2 路由配置

首先我们需要进行路由表的配置，让 A 知道应该以 B 为网关来来访问 192.168.3.0/24 子网。在 A 上运行

1
sudo ip route add 192.168.3.0/24 via 10.0.0.3

然后，我们需要在 B 上启用 IP 转发。在Linux系统中开启IP转发功能，可以通过以下步骤：

  1. 临时开启（系统重启后失效）
    • 对于基于Debian或Ubuntu的系统，可以使用以下命令：
      • 查看当前IP转发状态：cat /proc/sys/net/ipv4/ip_forward，如果输出为0，则表示IP转发功能是关闭的；如果输出为1，则表示IP转发功能是开启的。
      • 开启IP转发：sudo sysctl -w net.ipv4.ip_forward=1。这条命令会在运行时修改内核参数，使系统能够进行IP转发。
    • 对于基于Red Hat或CentOS的系统，操作如下：
      • 查看IP转发状态：cat /proc/sys/net/ipv4/ip_forward。
      • 开启IP转发：sudo sysctl -w net.ipv4.ip_forward=1。这会立即生效，但是在系统重启后会恢复到原来的设置。
  2. 永久开启（系统重启后依然有效）
    • 在Debian或Ubuntu系统中：
      • 编辑/etc/sysctl.conf文件：sudo nano /etc/sysctl.conf。
      • 在文件中找到#net.ipv4.ip_forward=1这一行（如果没有这一行，可以添加），将前面的#去掉，使这一行变为net.ipv4.ip_forward = 1。保存并退出文件。
      • 使配置生效：sudo sysctl -p。这条命令会重新加载sysctl.conf文件中的配置，使IP转发功能在系统重启后依然有效。
    • 在Red Hat或CentOS系统中：
      • 编辑/etc/sysctl.conf文件：sudo vi /etc/sysctl.conf。
      • 找到net.ipv4.ip_forward = 0这一行，将0改为1。保存并退出文件。
      • 执行sudo sysctl -p命令，让配置生效，这样在系统重启后IP转发功能也会开启。

3 防火墙配置

完成路由配置之后，A 机器能够知道到达 192.168.3.0/24 子网的路由路径，但是此时让 A 直接访问 C 的地址会失败，因为他们之间的通信会被 B 的防火墙拦截。因此我们需要对防火墙进行进一步配置。防火墙的配置分为两个主要的步骤：首先我们需要允许经过 B进行路由的数据包经过防火墙。在 B 上运行下面的代码：

1
2
sudo iptables -A FORWARD -i tun0 -o enp2s0 -s 10.0.0.0/16 -d 192.168.3.0/24 -j ACCEPT
sudo iptables -A FORWARD -i enp2s0 -o tun0 -s 192.168.3.0/24 -d 10.0.0.0/16 -j ACCEPT

注意其中的 -i -o 指定的接口名称需要针对你的服务器的实际情况调整。这里我们进行的往返路由路径的分别配置，将路由策略都设置为 ACCEPT 使得数据包能够通过 B 的防火墙。

对防火墙进行配置的第二个步骤是在 B 上开启地址伪装，即 MASQUERADE 机制。注意到我们在 A 上配置了路由表，但是没有作为访问目标的 C 则并不知道通向 A 的路由路径（A 和 B 之间在的 VPN 私有网络中是直通的，不需要额外路由）。因此我们需要配置进行一个额外的配置，即在 B 中开启地址伪装，此时 B 会将来自 A 的，以 C 为目标的数据包的源地址修改为自身的地址，那么 C 会认为这个包来自 B，响应也会被发送给 B，B 再将包转发回到 A。要开启地址伪装，需要在 B 上开启 iptables 配置：

1
sudo iptables -t nat -A POSTROUTING -s 10.0.0.0/16 -o enp2s0 -j MASQUERADE

注意上面的命令结果会在重启后失效。要持久化 iptables 命令的配置，可以采用下面的方法：

  1. 使用iptables - save和iptables - restore命令（适用于大多数Linux发行版）
    • 保存配置：
      • 首先，使用iptables - save命令可以将当前的iptables规则保存到一个文件中。例如，可以将规则保存到/etc/iptables.rules文件中，命令如下：sudo iptables - save > /etc/iptables.rules。
      • 这个命令会将当前活动的iptables规则以文本格式输出并保存到指定的文件。输出的内容包含了表（如filter、nat、mangle）以及每个表中的链（如INPUT、OUTPUT、FORWARD）的规则。
    • 恢复配置：
      • 要在系统启动时自动恢复这些规则，可以在合适的启动脚本中添加iptables - restore命令。例如，在基于Debian或Ubuntu的系统中，可以创建一个脚本文件（如/etc/network/if - post - up.d/iptables - restore），并在其中添加以下内容： 
        1
        2
        #!/bin/sh
        iptables - restore < /etc/iptables.rules
        然后给这个脚本文件添加可执行权限：sudo chmod +x /etc/network/if - post - up.d/iptables - restore。
      • 在基于Red Hat或CentOS的系统中，可以将iptables - restore命令添加到/etc/rc.d/rc.local文件中（不过要确保rc.local文件有可执行权限），如：iptables - restore < /etc/iptables.rules。这样，在系统启动后，iptables规则就会根据保存的文件进行恢复。
  2. 使用iptables - persistent工具（适用于Debian和Ubuntu系统）
    • 安装iptables - persistent：
      • 在Debian或Ubuntu系统中，可以使用以下命令安装iptables - persistent工具：sudo apt - get install iptables - persistent。
      • 这个工具会自动在安装过程中保存当前的iptables规则，并且会创建一些系统服务相关的配置来确保规则在系统启动时自动加载。
    • 保存和恢复规则：
      • 安装完成后，iptables规则会被自动保存到/etc/iptables目录下的文件中（/etc/iptables/rules.v4用于IPv4规则，/etc/iptables/rules.v6用于IPv6规则）。
      • 在系统启动时，iptables - persistent服务会自动读取这些文件中的规则并恢复iptables配置。如果后续修改了iptables规则，想保存新规则，可以使用sudo iptables - save > /etc/iptables/rules.v4（对于IPv4）和sudo iptables - save > /etc/iptables/rules.v6（对于IPv6）命令手动保存，或者使用dpkg - reconfigure iptables - persistent命令重新配置并保存规则。
  3. 使用systemd服务（适用于有systemd的Linux发行版）
    • 创建systemd服务单元文件：
      • 可以创建一个自定义的systemd服务单元文件来保存和恢复iptables规则。例如，创建一个名为iptables - save - service.service的文件，内容如下： 
        1
        2
        3
        4
        5
        6
        7
        8
        [Unit]
        Description=Save iptables rules
        After=network.target
        [Service]
        Type=oneshot
        ExecStart=/usr/bin/iptables - save > /etc/iptables.rules
        [Install]
        WantedBy=multi - user.target
      • 将这个文件保存到/etc/systemd/system/目录下，然后使用systemd命令来管理这个服务。
    • 启用和启动服务：
      • 执行sudo systemd - enable iptables - save - service.service命令来设置服务在系统启动时自动运行。
      • 可以使用sudo systemd - start iptables - save - service.service命令来手动启动服务，保存当前的iptables规则。
      • 同时，还需要创建一个用于恢复规则的服务单元文件，例如iptables - restore - service.service，内容如下： 
        1
        2
        3
        4
        5
        6
        7
        8
        [Unit]
        Description=Restore iptables rules
        After=network.target
        [Service]
        Type=oneshot
        ExecStart=/usr/bin/iptables - restore < /etc/iptables.rules
        [Install]
        WantedBy=multi - user.target
      • 同样将这个文件保存到/etc/systemd/system/目录下，然后使用systemd - enable iptables - restore - service.service命令来设置在系统启动时自动恢复规则，并且可以使用systemd - start iptables - restore - service.service命令手动启动恢复规则的服务。

引发 LTO 优化后续错误的一种可能及解决方法

✇治部少辅
作者 治部少辅
2024年5月31日 14:02

最近开发 C++ 的程序在链接阶段发生了一个 LTO 相关的错误。链接时优化（Link Time Optimization, LTO） 是一种编译优化技术，旨在通过在链接阶段执行全程序优化来提升代码性能和减少二进制文件大小。其主要原理是在链接阶段而不是在编译阶段进行更高级的优化，允许跨文件的全局优化。LTO 的基本原理和过程是：

  • 中间表示：在编译阶段，编译器将每个源文件编译为一种中间表示（如 LLVM bitcode），而不是直接生成目标代码。
  • 全局优化：在链接阶段，链接器将所有中间表示文件合并，生成一个完整的程序表示。此时，优化器可以进行跨文件的全局优化，如函数内联、去除冗余代码和跨模块优化。
  • 生成目标文件：优化完成后，链接器生成最终的可执行文件或库。

我遇到的错误信息中的管件一句是:

1
attempt to add bitcode file after LTO (htons)

可以看到错误信息提示我们链接系统试图在 LTO 优化之后添加 bitcode。并且在后面的括号中链接器提到了一个符号 htons，这是来自 libc 库的一个符号。基于的 https://github.com/emscripten-core/emscripten/issues/16836 这个链接中的启发，我发现了一个 LTO 优化可能面临的普遍性问题。这个问题是 LTO 会尝试移除一些它认为不需要的符号从而减少编译出来的程序的体积，但是这个判断可能会不准确。它可能将一些实际会被使用的符号删除。为了解决这个问题，我们可以为链接器指定链接输入，强制保留指定的符号以避免错误的移除。针对我遇到的情况，为链接器加上 -Wl,-u,htons 的配置即可解决问题。

  • -Wl: 这个标志告诉编译器将接下来的选项传递给链接器（ld）。-Wl,option 是传递给链接器的标准方法。
  • -u,symbol: 这个选项告诉链接器强制包含指定的符号 symbol。在这个情况下，-u,htons 和 -u,htonl 告诉链接器强制包含 htons 和 htonl 函数

Unraid 上 Nextcloud 的部署问题

✇治部少辅
作者 治部少辅
2023年9月3日 14:56

之前我写过一篇文章来吐槽 Nextcloud 的性能问题。当时我是尝试在群晖上试用 Nextcloud。考虑到我使用的群晖服务器的 CPU 性能比价差，因此我尝试在 Unraid 上部署 Nextcloud。但是性能差的问题仍然没有改观。不过近期在 Unraid 发布了 6.12.0 版本以后这个问题得到了很大的改观。

1 问题分析

问题出在 shfs 这个进程上。在 Unraid 中，这个进程负责将分散在各个 Disk 上的文件夹内容聚合成一个统一的目录库，这意味着如果我们要访问任何文件都需要通过 shfs 来查找文件，这也使得 shfs 成文高吞吐率场景下的一个性能瓶颈。之前我经常可以看到 shfs 的 CPU 占用飙升到 100% 甚至 200%。在新版的 Unraid 中提供了 exclusive access 的特性。 Exclusive 的是排他性，独占的意思。Exclusive Access 是指固定将一个目录放在一个 Disk 中，这样我们在访问这个目录下的文件时，就不需要通过 shfs 来检索目录，而是可以直接访问磁盘上的目录系统，从而降低开销。

另一方面，Exclusive 也意味着这个目录无法有效的利用磁盘阵列提供的存储池，而只能利用单磁盘空间。因此，Nextcloud 的数据文件夹是不能使用 Exclusive Access 的。不过好在数据文件的访问其实并不是主要瓶颈，造成 Nextcluod 卡顿的主要原因在对容器挂载的配置文件（也就是 appdata）里面的众多小文件的高频读写。

另一个需要指出的是，在 Unraid 中，尽管缓存有多个 SSD，但是这些 SSD 会预先通过 Raid 机制聚合成一个统一的缓存磁盘，对于 Shfs 来说这个缓存池就是一个单一的磁盘，因此对缓存池的访问可以启用 Exclusive Access

2 如何使用

要是用 Exclusive Access，首先需要再 Settings --> Global Share Settings 下打开（如下图，将 Permit exclusive shares 设置为 yes）。

但是在共享目录使用时，Exclusive Access 的含义是比较模糊的。因为 Share 的管理界面并不会提供一个可以由用户可以直接控制的选项来为具体的 Share 开启 Exclusive Access。事实上，Exclusive Access 是否会起作用是系统根据目录的状态来自动确定的。如前文所述，Exclusive Access 作用的前提是数据只位于一个磁盘中。因此，在 Permit exclusive shares 启用的前提下，如果某个 Share 的文件只可能位于一个磁盘中，那么 Exclusive Access 将自动启用。

要实现 Share 的文件只属于一个磁盘中，需要满足一下条件：

  1. Share 只启用了一个 Storage，没有 Secondary Storage
  2. 如果 Share 是存储在 Array 中的，在设置 Include disks 时只能选择一个磁盘；
  3. 如果是事先已经存在的目录，那么在满足上两条的情况下，还需要通过适当的 Mover 动作，将数据迁移到单一磁盘中。（注意如果之前 Share 是存在多个磁盘中时，做前两条修改，并不会自动将数据迁移到目标磁盘）

在本文的场景中，我们需要在 appdata 这个共享目录上启用 Exclusive Access，就可能需要进行必要的 Mover 操作。如果你看到 appdata 的 Share settings 页面中显示了如下 Exclusive access: no 的文字，进行如下操作：

  1. 出现这个状态，说明你的 appdata 并不完全位于缓存中，有一部分是位于阵列中的，此时我们需要让 Mover 将数据从阵列中移动到缓存中。注意：
    1. 如果在现在的状态下，你的 appdata 是 Cache only 的，但是你仍然看到 Exclusive access: no，这是因为曾经某个时刻你为 appdata 设置了阵列存储的选项（以老版本的术语来说，就是 use cache 不是 only，而是 yes 和prefer 的选项），那么在那个时间段内，shfs 可能会将数据文件调度到阵列上。此时即便你讲 appdata 设置为 cache only，Mover 也不会自动将文件从阵列迁移到缓存。修改共享目录的这些相关设置只会影响新文件，而不会直接影响已有文件。
    2. 在上面这种情况下，你需要首先恢复缓存-阵列两级缓存架构，然后将 Mover 行为设置为 prefer cache（在 6.12,0 的属于下，是将 Mover action 设置为 Array -> Cache。然后运行 Mover 完毕。这时 Mover 会将还停留在阵列上文件移动到缓存（当然前提是的缓存的空间要够）。
    3. 完成上面的操作之后，我们再将 appdata 设置为 cache only 的形式（Primiary Storage 为缓存，无 Secondary Storage），这时我们应该能够看到 Exclusive access 变成了 yes。

3 结语

上面的这套操作，能够极大改善 Nextcloud 在 Unraid 上的表现。其他的应用也会有很大的改观（例如 Jellyfin 的打开和搜索速度会有质的提升）。

Ubuntu 中如何彻底删除一个用户

✇治部少辅
作者 治部少辅
2023年8月16日 18:51

在 Ubuntu 中彻底删除一个用户涉及到几个步骤，不仅仅是删除用户，还可能包括删除与用户相关的数据。以下是步骤指南：

  1. 确保用户未登录: 在删除用户之前，最好确保该用户未登录。你可以使用 who 命令来检查哪些用户当前已登录。

    1
    who

  2. 删除用户: 使用 userdel 命令删除用户。如果你还希望删除用户的主目录和邮件池，可以使用 -r 选项。

    1
    sudo userdel -r username

    其中，username 是你想删除的用户的用户名。

    注意：-r 选项会删除用户的主目录（通常是 /home/username）。确保你已经备份了所有重要的数据！

  3. 检查文件系统: 即使删除了用户和其主目录，可能仍然在文件系统上遗留一些属于该用户的文件。你可以使用 find 命令来搜索这些文件：

    1
    sudo find / -user username

    这将列出所有属于 username 的文件。根据你的需要，你可以手动删除这些文件或更改它们的所有权。

  4. 删除用户的 cron 作业: 如果用户配置了任何 cron 作业，你还需要手动删除它们。检查 /var/spool/cron/crontabs/username 是否存在，如果存在，删除它。

    1
    sudo rm /var/spool/cron/crontabs/username

  5. 其他服务或配置: 如果该用户有其他特定的配置，例如在 /etc/sudoers 中的条目或在其他服务中的特殊访问权限，你需要手动检查并删除它们。

请在进行任何删除操作之前确保备份所有重要数据。确保你明确知道正在执行的操作，避免意外删除重要文件或配置。

读论文: Segment Anything

✇治部少辅
作者 治部少辅
2023年5月11日 16:32

这是 Meta 最近发布的一篇挺火的论文，标题就是 Segment Anything，也可以称之为 Segment Anything Model，简称 SAM。这个模型的野心很大，试图建立起一个“大一统”的分割模型，可以对任意类别的元素完成像素级分割；

为了达成这个任务，作者建立了一个极为庞大的数据集，包含了 1100 万个样本上的 10 亿个 Mask。这个数据集的名字叫做 SA-1B。作者还引入了一个 promptable segmentation 的概念，即我们可以通过输入文本来控制被 Segment 标记出来的像素集合的类别，如上图 (a) 所示。

参考大语言模型中在近期取得突飞猛进的进展，如果在图像领域也构造出足够强大的通用模型成为一个新的热点。本文的目标就是为图像分割任务训练一个基础的通用模型。另一个重点是将图像分割筒 Prompt 工程集合起来。

读论文：CADTransformer

✇治部少辅
作者 治部少辅
2023年4月11日 14:42

这次要读的文章是 CADTransformer: Panoptic Symbol Spotting Transformer for CAD Drawings

这篇论文介绍了一个名为CADTransformer的新框架，用于自动化CAD图纸中的全景符号识别任务。该任务需要识别和解析可数对象实例（如窗户、门、桌子等）和不可数的物品（如墙壁、栏杆等），并在CAD图纸中进行标记。该任务的主要难点在于图纸中符号的高度不规则的排序和方向。现有方法基于卷积神经网络（CNNs）和/或图神经网络（GNNs）来回归实例边界框并将预测结果转换为符号。相比之下，CADTransformer直接从CAD图形原始集合中进行标记，通过一对预测头同时优化线条级别的语义和实例符号识别。此外，该框架还通过几个可插拔的修改增强了主干网络，包括邻域感知自注意力、分层特征聚合和图形实体位置编码等。此外，该论文还提出了一种新的数据增强方法，称为随机层（Random Layer），通过CAD图纸的分层分离和重组来进行数据增强。最终，CADTransformer在最新发布的FloorPlanCAD数据集上，将先前的最先进水平从0.595提高到0.685，展示了该模型可以识别具有不规则形状和任意方向的符号。

1 Introduction

1.1 关于 CNN 网络的准确性问题

在 CAD 文件中对图元要素分类的任务在本文中被称为 Symbol Spotting。这类任务在建筑行业和其他工业领域都要广泛的应用前景。Symbol Spotting 任务分类的目标是具有几何特征或更多异质特征的图元要素，不同的是，传统的基于计算机视觉，尤其是基于 CNN 网络的图像分割任务，其分割的目标元素是同质化的像素。由于存在遮挡、非均匀聚集、制图风格差异等原因，Symbol Spotting 任务具有较大的难度。

传统的 Symbol Spotting 采用的是一种名为 Query-by-example，望文生义地来看，这些方法需要提前指定特定的符号构成，然后以匹配的方式寻找图面中与之类似的元素。这种方法显然无法适应现实中复杂多变的画图方式。近年来也涌现了一些基于机器学习的方法，他们提出使用 CNN 方法来解决 Symbol Spotting 问题。但是将 CAD 矢量数据本身转化成位图天然就引入了精度损失，这使得这些方法存在先天性不足。

以建筑行业为例，建筑 CAD 图纸具有“高对比度”（或者说“高灵敏度：）的特点，在一个 100 米乘 100 米的平面空间内，在围观层面上要求达到 1 毫米的精度。为了保持这个精度，我们必须将其转化成 10 万像素乘 10 万像素的位图，这个尺寸的图像处理起来代价过于高昂。而如果减少像素数量，则无法保持 1 毫米的精度。

这篇论文的团队在之前的发表的论文中提出了 FloorPlanCAD 数据集。基于这个数据集可以训练能够进行 Panoptic Segmentation Task 的模型。这类任务是综合了实例分割和语义分割的复合任务。在 CAD Symbol Spotting 场景，这意味着需要同时得到图元级别的类型归属和具有语音含义的每个建筑构件的识别。

本文的作者通过引入图卷积神经网络 (GCN) 来解决 Symbol Spotting 问题。GCN 网络可以给出每个图元的语义信息，同时还有一个 CNN 网络来给出“可数”构件的实例分割结果。

1.2 Transformer 的作用

基于 Transformer，可以在不预先定义图连接结构的情况下，基于注意力机制推断到 tokens 之间的全局关系 (Transformers reason global relationships across tokens without pre-defined graph connectivity, by instead learning with self-attention)。这使得 Transformer 可以在 panoptic symbol spotting 任务中替代 GCN 的作用。但是标准的 Transformer 在这类任务上的使用仍然存在一些挑战：

  1. Tokenization and position encoding of graph symbols：前者是编码的问题，后者则是典型的 ViT 引入的问题。典型的 ViT，即 Visual Transformer 会将每个图像划分成 或者 个 Patch，即 token，同时基于这个二维网格分布可以将这些 token 的顺序线性化，并组合在一起。不过在 CAD 数据中，图元数据的排列是无序的，且坐标数值属于连续的实数空间，并非离散化，这和栅格化的图像有根本性的不同。
  2. Inmense set of primitives in certain scenes. ViT 的全局注意力机制的复杂度相比于 token 的数量是四次方的，如果是处理 CAD 数据，由于图元的数量非常庞大，这个数量级的复杂度是无法处理的。
  3. Training data limitations. ViT 架构能够提供更多灵活性的同时，其对数据的需求量也更大了。

作者提出的 CADTransformer 旨在成为一个通用的框架，可以被轻易地和现有的 ViT 骨干网络整合起来。

CADTransformer 是作为一个完整的 ViT 处理 Pipe 的一部分被插入到图像处理流程中。

2 Methodology

2.1 Overview

一般意义上的 Panoptic symbol spotting 任务可以表述为 ，其中 表示一个基础图元。 和 分别是此图元的语义标签与实例索引。对于输入的 CAD 矢量图纸，我们首先将其拆解成基础图元要素（弧线、多段线等），并将图纸转换成栅格化后的位图。图元的嵌入的获取方式是将每个图元投影到一个预训练的 CNN 网络输出的二维特征图上。基于这个这样获取的嵌入，使用一个标注你的 Vision Transformer 以及作者提出的可插拔的附加网络，模型可学习到不同的 Token 之间的关系。Transformer 层后面跟着的是 Two-Branch heads 结构，我们可以通过这个结构来优化图元级预测的精度。本文提出的模型的整体结构如下图所示

具体而言，图元 Embeding 获取的方式是将图纸的栅格化图像输入 HRNetV2-W48 这个预训练网络。此网络是一个多级多分辨率的网络，我们取不同分辨率的分支，拼成一个 的张量。对于每个几何图元，我们将其中心点投影到这个张量的第二、三个维度张成的平面上，去第一个维度的特征值构成特征向量。这样最终得到所有 token 的 Embedding 就是 ，其中 是图元的数量， 是 Embedding 的维度。

2.2 Two-Branch heads

如前文所述，Two-Branch heads 提出的目的是优化预测精度。TBH 层以 Transformer 骨干网络输出的几何 Embedding 为输入。

2.2.1 语义分割

对于聚合后的 Transformer 特征输出 ，施加一个 MLP 层，可以生成一个语义分数 。损失函数使用交叉熵 。

2.2.2 实例分割

CAD 图纸场景中的实例分割结果无法简单地用 BoundingBox 来表示。作者提出了一个新的方法，不是在像素图像中预测 2D BoundingBox，而是针对每个图形实体预测一个偏移向量，以便将实例实体聚集在一个公共的实例中心周围。为了更好地将实例相关的图元聚类在一起，作者使用一系列的 MLP 来编码图元的 Embedding，进而产生 个偏移向量 。针对这个偏移量的训练使用 损失函数。

其中 是一个指示变量组成的向量，只有可数构件的图元参与这个计算。在经过这个 Offset 量处理之后，可以用聚类算法对偏移后的图元中心点进行聚类。

2.3 Improve Transformer Backbone Design for Better Spotting

ViT 骨干网络以上述编码层的输出，即 Tokenization Module 的输出作为输入，执行自注意力机制，并生成送往 Two-Branch Head 网络的特征表示。

2.3.1 Self-Attension with Neighbor Awareness

典型的 ViT 的架构由多个 Transformer 层组成，每层包含一个 self-attention 模块和一个前馈网络（Feed-Forward Network) 。自注意力机制的计算方式为：

其中 分别是 query, key 和 value 矩阵， 和 表示样本数量和隐藏层维度。

然而，图纸中图元的数量非常多，因此全局注意力复杂度太高。为了解决这个问题，作者提出以下改进方法。

2.3.2 Self-attention with k Neighbors

让注意力机制的计算只在图元最邻近的 k 个邻居之间进行计算，这样可以限制复杂度随着图纸规模增长的速度。这里的临近关系通过计算起始点和终止点的距离来实现。

其中 和 表示图元 的起始点和终止点， 是目标图元， 表示其他图元。增加注意力机制计算中考虑的临近的图元数量可以增加感知的范围。作者提出的 Transformer 主干网络划分成了若干个阶段，每经过一个阶段会提提高 的值。

2.3.3 Multi-resolution Feature Fusion

我们将不同阶段得到的特征输出整合起来，令

2.3.4 Graphic Entity Position Encoding

由于图元数据天然来自于二维欧式空间，因此可以的比较容易的定义位置编码：

2.4 Random Layer Augmentation

本章节介绍的是一种数据增强策略。这个策略很简单，就是利用 CAD 图纸的图层结构信息，将图层划分为是哪个类别，分别是 Thing layer, Stuff layer 和 Background Layer。我们让这些层内随机挑选出的若干层组成新的图纸。

使用 Shadowsocks 访问 ChatGPT 频繁出现 Something Went Wrong 问题的解决方法

✇治部少辅
作者 治部少辅
2023年3月28日 18:16

update at 2023.4.27：

Github 上有人做了一个开源的油猴脚本 KeepChatGPT 可以解决这个问题。在浏览器上这个脚本可以正常使用，但是注入到客户端时（尽管内部仍然是一个浏览器）会出现错误。

update at 2023.4.12：

在 Windows 上这套方法存在一定的问题。可能的原因是 Proxifier 的代理权限有时候会被 Shadowsocks 客户端，也就是 Privoxy 争抢。

由于国情原因我们使用使用 ChatGPT 需要使用各种形式的代理，这时我们肯能会发现在与 ChatGPT 对话的过程中可能会出现下面的错误：

Something went wrong. If this issue presists please contact us through our help center at help.openai.com

这种错误一般在我们再让网页空闲一段时间（通常是一分钟）后再次提问时出现。当然，去 OpenAI 的帮助中心是不会搜到什么有用的信息的。如果你去检索这个问题，你能得到的最好答案是在出现这个页面之后刷新页面，然后回到对话窗口继续对话即可。但是刷新后如果再次出现空闲窗口的情况，这个问题会反复出现，因此你在对话中就不得不反复地刷新页面，再加上每次页面重载你都需要去勾选 Cloudflare 的机器人验证框，这就会极大程度上拖慢我们的速度，影响产品体验。

这个问题是否可能是由于我翻墙访问导致的呢？我使用的翻墙软件是 Shadowsocks，经过一番搜索，一个 Github Issue 的讨论给了我灵感。

讨论地址：https://github.com/shadowsocks/shadowsocks-libev/issues/2149

尽管讨论的题目和 ChatGPT 没有直接关系，但是这个回复提到，Shadowsocks 在构建代理管道时，会在客户端使用 Privoxy 来讲 Socks5 代理转换成 http 代理，进而被浏览器使用。Privoxy 的配置中包含了 Socket 连接时长方面的控制。于是我查看了我本地的 Shadowsocks 使用的 Privoxy 的配置文件，这个文件在 MacOS 中位于 /Users/lena/Library/Application Support/ShadowsocksX-NG/privoxy.config 文件。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
toggle  1
enable-remote-toggle 1
enable-remote-http-toggle 1
enable-edit-actions 0
enforce-blocks 0
buffer-limit 4096
forwarded-connect-retries  0
accept-intercepted-requests 0
allow-cgi-request-crunching 0
split-large-forms 0
keep-alive-timeout 5
socket-timeout 60

forward         192.168.*.*/     .
forward         10.*.*.*/        .
forward         127.*.*.*/       .
forward         [FE80::/64]      .
forward         [::1]            .
forward         [FD00::/8]       .
forward-socks5 / 127.0.0.1:1086 .

# Put user privoxy config line in this file.
# Ref: https://www.privoxy.org/user-manual/index.html

可以看到 keep-alive-timeout 和 socket-timeout 这两个选项设定的超时时间都比较低。我做了下面两个尝试：

  1. 将这两个设置调高，并重启 Shadowsocks，但随后发现 Privoxy 重置了设置文件；
  2. 我手动 kill 掉正在运行的 Privoxy 并且手动使用更新后的 config 文件调起一个新的进程，但是仍然没有解决 Something went wrong 的问题；

至此，我也不想和 Privoxy 纠缠下去，既然问题出在 Socks5 代理转 Http 代理的环节，我们可以使用 Proxifier 这个软件直接使用 Shadowsocks 提供的 Socks5 代理，就可以很好地解决这个问题。

Proxifier 的教程网上非常多，我就不在这篇文章里赘述了。

Proxifier 的使用参加我的文章：如何使用 Proxifier 来进行流量代理控制

❌
❌