1
bfjm 2024-11-25 17:08:21 +08:00 via iPhone
xid 大小是否超过了 2 xid 是否有线程安全问题
|
4
billccn 2024-11-26 02:01:49 +08:00
你是怎么定位到这行代码的?
这代码看上去人畜无害,除非编译器认为 xid.size()必定小于 2 ,于是编译了个 undefined behavior 进去? 当然编译问题也是有可能的,你有保留这行代码然后 clean 编译过一次吗? |
5
vfx666 OP @billccn 一点点排除定位到的问题,因为测试了软件之前的发行版没有问题,这就可以把范围缩小到具体的代码段了。然后进一步缩小排除,最后发现就是这么一行
保留这行代码,即使此代码并没有被执行(写一个 if 判断故意跳过这行)还是会触发问题。你说的 clean 编译是指的那个“重新编译…”选项吗 |
6
w568w 2024-11-26 09:43:32 +08:00
|
8
araraloren 2024-11-26 10:42:09 +08:00
haha
|
9
Promtheus 2024-11-26 11:05:41 +08:00
|
10
realpg PRO 先改写这一行
xid.erase(xid.end() - 2, xid.end()); 拆语句成 tmp_a = xid.end() tmp_b = tmp_a -2 log tmp_a, tmp_b to logfile with current timestamp xid.erase(tmp_b,tmp_a) |
11
lixile 2024-11-26 14:10:57 +08:00
大概率 overflow 了 只是这行代码所在参与编译后 导致崩溃的内存位置被 overflow 到了
不参与时 overflow 位置 没有涉及关键内存 |
12
billccn 2024-11-26 18:30:05 +08:00
@vfx666 等等,一楼问你 xid 大小有没有超过 2 ,你二楼回答没有。那 xid 的大小会不会不到 2 ?你加的 if 是检测 xid 的长度吗?不是的话能不能加一个试试?可能其他部分就有 bug ,导致 xid 偶尔不到 2 个长,之前没有做 erase 所以没有发现?
然后,11 楼说的是很有可能的,因为你这行代码虽然不执行,但是为了能执行这行代码,编译器可能改变了堆栈帧的长度,或者初始化了某些信息,这导致其他(已有的)代码 overflow 到了更关键的地方。 但我们这都是凭空猜测,你要想方设法弄到个 stack 。 |