Bug Description / 错误描述
使用 latx-x86_64 执行 OpenSSL 的 speed 子命令时有一定概率会卡住。
Environment Information / 环境信息
操作系统: AOSC OS 12.2.2
Linux 内核版本: 6.17.7-aosc-main-16k
GCC 版本: 14.3.0
GLIBC 版本: 2.40
LAT 版本号 / 提交 Hash: 42280cb
Steps to Reproduce / 重现步骤
Describe the issue in detail
详细描述问题
卡住时输出如下：
k@lobster [ ~ ] $ ~/Documents/git/lat/build64/latx-x86_64 /usr/gnemul/lat-x86_64/usr/bin/openssl speed -evp aes-128-gcm
option avx cpuid 1
Doing AES-128-GCM ops for 3s on 16 size blocks:
卡住的程序仍然会在前台占用 100% CPU，手动发送 SIGKILL 能正常杀掉它。
Software Information (e.g., name, version, configuration, etc.)
使用的软件信息（例如：名称、版本、配置等）
AOSC OS emukit 20251105~pre20251105T023451Z
k@lobster [ ~ ] $ ~/Documents/git/lat/build64/latx-x86_64 /usr/gnemul/lat-x86_64/usr/bin/openssl version
option avx cpuid 1
OpenSSL 3.5.4 30 Sep 2025 (Library: OpenSSL 3.5.4 30 Sep 2025)
测试过 latx-1.6 和 latx master (42280cb)，均会出现这个问题。
Expected Behavior / 预期行为
每项测试都应该在开始之后第三秒自动结束，并打印性能数据。以 LoongArch64 原生的 OpenSSL 3.5.4 为例，执行同样的命令会输出如下结果：
k@lobster [ ~ ] $ /usr/bin/openssl speed -evp aes-128-gcm
Doing AES-128-GCM ops for 3s on 16 size blocks: 3389446 AES-128-GCM ops in 3.00s
Doing AES-128-GCM ops for 3s on 64 size blocks: 2083211 AES-128-GCM ops in 3.00s
Doing AES-128-GCM ops for 3s on 256 size blocks: 814119 AES-128-GCM ops in 3.00s
Doing AES-128-GCM ops for 3s on 1024 size blocks: 238737 AES-128-GCM ops in 3.00s
Doing AES-128-GCM ops for 3s on 8192 size blocks: 31396 AES-128-GCM ops in 3.00s
Doing AES-128-GCM ops for 3s on 16384 size blocks: 15682 AES-128-GCM ops in 3.00s
version: 3.5.4
built on: Wed Oct 1 14:51:55 2025 UTC
options: bn(64,64)
compiler: gcc -fPIC -pthread -Wa,--noexecstack -pipe -Wno-error -fstack-protector-strong --param=ssp-buffer-size=4 -fexceptions -ggdb -fira-loop-pressure -fira-hoist-pressure -specs=/usr/lib/gcc/specs/hardened-cc1 -O3 -fno-omit-frame-pointer -flto=auto -mabi=lp64d -mno-strict-align -march=la64v1.0 -mtune=la664 -Wa,--noexecstack -D_GLIBCXX_ASSERTIONS -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -pipe -Wno-error -fstack-protector-strong --param=ssp-buffer-size=4 -fexceptions -ggdb -fira-loop-pressure -fira-hoist-pressure -specs=/usr/lib/gcc/specs/hardened-cc1 -O3 -fno-omit-frame-pointer -flto=auto -mabi=lp64d -mno-strict-align -march=la64v1.0 -mtune=la664 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG -D_GLIBCXX_ASSERTIONS -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3
CPUINFO: N/A
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
AES-128-GCM 18077.05k 44441.83k 69471.49k 81488.90k 85732.01k 85644.63k
Actual Behavior / 实际行为
测试偶尔能全部跑完，但大概率会在中途卡住。
Screenshots or Logs / 截图或日志
Severity / 严重性
Critical / 严重
Additional Information / 附加信息
使用 strace 后能发现，程序收到了 SIGALRM，但本该停止测试的 signal handler 似乎并没有起效。于是我写了个结构类似 openssl speed 的简易测试：
#include <stdio.h>
#include <unistd.h>
#include <signal.h>
static volatile sig_atomic_t run = 0;
const char SIGNAL_HANDLER_MESSAGE[] = "Signal Handler: run set to 0\n";
// Adapted from OpenSSL apps/speed.c L152
static void alarmed(int sig)
{
signal(SIGALRM, alarmed);
run = 0;
write(STDOUT_FILENO, SIGNAL_HANDLER_MESSAGE, sizeof(SIGNAL_HANDLER_MESSAGE) - 1);
}
int main() {
printf("Setting up signal handler...\n");
signal(SIGALRM, alarmed);
run = 1;
alarm(1);
size_t count = 0;
printf("Entering tight loop...\n");
while (run) {
count++;
}
printf("Success! Loop exited. Count: %llu\n", count);
return 0;
}使用 AMD64 的 GCC 14.2.0 编译后，在一个死循环内使用 latx-x86_64 重复执行该程序可以稳定复现这个问题：
k@lobster [ tmp ] $ while true; do ~/Documents/git/lat/build64/latx-x86_64 /tmp/test; done
option avx cpuid 1
Setting up signal handler...
Entering tight loop...
Signal Handler: run set to 0
Success! Loop exited. Count: 287017891
<...>
option avx cpuid 1
Setting up signal handler...
Entering tight loop...
Bug Description / 错误描述
使用 latx-x86_64 执行 OpenSSL 的 speed 子命令时有一定概率会卡住。
Environment Information / 环境信息
操作系统: AOSC OS 12.2.2
Linux 内核版本: 6.17.7-aosc-main-16k
GCC 版本: 14.3.0
GLIBC 版本: 2.40
LAT 版本号 / 提交 Hash: 42280cb
Steps to Reproduce / 重现步骤
Describe the issue in detail
详细描述问题
卡住时输出如下：
卡住的程序仍然会在前台占用 100% CPU，手动发送 SIGKILL 能正常杀掉它。
Software Information (e.g., name, version, configuration, etc.)
使用的软件信息（例如：名称、版本、配置等）
AOSC OS emukit
20251105~pre20251105T023451Z测试过 latx-1.6 和 latx master (42280cb)，均会出现这个问题。
Expected Behavior / 预期行为
每项测试都应该在开始之后第三秒自动结束，并打印性能数据。以 LoongArch64 原生的 OpenSSL 3.5.4 为例，执行同样的命令会输出如下结果：
Actual Behavior / 实际行为
测试偶尔能全部跑完，但大概率会在中途卡住。
Screenshots or Logs / 截图或日志
Severity / 严重性
Critical / 严重
Additional Information / 附加信息
使用 strace 后能发现，程序收到了 SIGALRM，但本该停止测试的 signal handler 似乎并没有起效。于是我写了个结构类似
openssl speed的简易测试：使用 AMD64 的 GCC 14.2.0 编译后，在一个死循环内使用 latx-x86_64 重复执行该程序可以稳定复现这个问题：