首页 > 解决方案 > 数组索引超出范围,但 gdb 报告错误的行 - 为什么?

问题描述

我是 C++ 初学者。我发现了一个奇怪的现象。GDB 无法在此代码中给出错误根本原因的行号。

#include <array>

using std::array;

int main(int argc, char **argv) {

    array<double, 3> edgePoint1{0, 0, 0};
    array<double, 3> edgePoint2{0, 0, 0};
    array<double, 3> edgePoint3{0, 0, 0};
    array<array<double, 3>, 3> edgePoints{};
    edgePoints[0] = edgePoint1;
    edgePoints[1] = edgePoint2;
    edgePoints[3] = edgePoint3;
    return 0;
}

第 13 行是问题的根源。但是当我在 GBD 中使用 'bt' 时,它会打印第 15 行。为什么?

Program received signal SIGABRT, Aborted.
0x00007f51f3133d7f in raise () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007f51f3133d7f in raise () from /usr/lib/libc.so.6
#1  0x00007f51f311e672 in abort () from /usr/lib/libc.so.6
#2  0x00007f51f3176878 in __libc_message () from /usr/lib/libc.so.6
#3  0x00007f51f3209415 in __fortify_fail_abort () from /usr/lib/libc.so.6
#4  0x00007f51f32093c6 in __stack_chk_fail () from /usr/lib/libc.so.6
#5  0x0000556e72f282b1 in main (argc=1, argv=0x7ffdc9299218) at /home/wzx/CLionProjects/work/test1.cpp:15
#6  0x0000000000000000 in ?? ()

标签: c++debugginggdbundefined-behavior

解决方案


调试器诊断实际错误。在将源代码转换为计算机可以运行的实际程序的非常复杂的过程之后,由于代码中的错误/错误而发生的事情。它不会分析 C++ 源代码中的错误/错误,实际上理论上也不能这样做(至少在一般情况下不会)。这里的实际错误是您的缓冲区溢出破坏了“堆栈”。您只看到报告的症状,而不是原始原因(缓冲区溢出本身)。

这有点像如果你不小心把车开到路上撞到树上,警察知道你把车撞到树上,但他们不会自动知道这是因为你在路上中风了轮子,或者因为你在发短信,或者因为你喝醉了。他们必须在事后调查以找出这些细节,使用其他(更间接的)证据,例如采访您或进行体检。

史诗般的车祸比喻(由我)

(请注意,电话从破碎的窗户飞出,落在树附近的地面上:它离司机的手不远——尽管坠机的原因是它在司机的手中。一个好的警察会意识到电话可能曾经在车内,根据屏幕上显示的半写文本消息,事故发生时可能在驾驶员手中。案件已结案,法官大人。解决方案:开车时停止发短信。)

这是 C++ 生活中的一个事实,这就是为什么我们在编写代码时需要仔细注意我们的代码,以免我们“自取其辱”。在这里您非常幸运地遇到了崩溃,否则您可能完全错过了该错误,而只是看到了意外/奇怪的行为!

随着时间的推移,随着经验的积累,你会越来越习惯这一点,并熟练地“环顾”或“靠近”报告的线路,看看是什么逻辑错误导致了实际问题。在大多数情况下,这是心理模式匹配。这也是为什么你不能“在 21 天内学会 C++”的原因!

确实存在一些工具可以使这更容易。静态分析工具可以查看您的代码,并且有时会发现您使用了不可能的数组索引。容器(例如arrayvector)可以通过额外的边界检查来实现(因为at()这是必需的;对于op[]某些实现,为了方便在调试模式下添加它)。将工具与经验相结合,取得巨大成功!


推荐阅读