水木社区手机版
- 主题:gcc一个挺出乎意料的问题
- 起因是：
下面的程序debug版本跑着没问题，但是release版本那条log会反复打印，而且gdb里能看到反复创建LWP线程。
有的时候gdb很卡，表现就是按了ctrl + c后很久才反应，断下来显示提示符。
注释掉创建线程的那句后，会崩在log语句里调用__libc_free() -> get_meta()释放字符串内存时。
int CMyClass::Start() {
m_thread = new std::thread(&CMyClass::ThreadProc, this);
log("started.");
}
这个代码本身是有编译警告的，提示没有return语句。
加了return语句后就好了，去掉return语句后就是上面的现象。
这有点出乎意料，因为一般对没加return语句的预期是这个函数会返回随机的值，而不是出现上述各种奇怪现象。
虽然"main()之外的non-void函数没有return语句"被规定为UB。
看了一下gcc 12.2.0生成的汇编，没有return语句时，就是一个死循环。
--
FROM 221.218.160.* - 文心的回答：
您的问题涉及到了C++的未定义行为（Undefined Behavior）以及GCC编译器在Release版本下的优化问题。
首先，C++标准规定，如果一个函数没有显式的返回语句，且函数的返回类型不是void，那么这个函数的返回值是未定义的。未定义行为是一种编译器不会进行任何错误检查的特殊行为，它可能会导致任何结果，包括看似合理的结果。
在你的代码中，如果函数没有返回语句，并且返回类型不是void，那么这个函数的返回值是未定义的。然而，这并不意味着程序会表现出随机行为。实际上，未定义行为可能会导致程序表现得像它已经返回了一个值，或者它可能陷入无限循环，或者它可能会崩溃，或者它可能会表现出任何其他看似不相关的行为。这是因为未定义行为可以导致任何结果，这取决于具体的实现和运行时环境。
在你的情况下，可能GCC编译器在Release版本下进行了某些优化，导致程序陷入无限循环。这可能是因为编译器发现函数没有返回语句，因此它决定将函数优化为永远不会返回，从而避免可能的资源浪费。
解决这个问题的方法是确保你的函数总是有一个明确的返回语句。即使你的函数只有一个简单的return语句，也会消除未定义行为的风险。
至于日志反复打印和GDB卡顿的问题，这可能是由于线程池反复创建线程导致的。如果你的线程池库没有正确地处理线程的创建和销毁，那么这可能会导致线程反复创建和销毁，从而导致不必要的开销和可能的竞争条件。你应该检查你的线程池库的文档，或者尝试使用一个更可靠和优化的线程池库。
最后，GDB卡顿可能是因为GDB试图在大量的线程上下文中调试你的程序，这可能会导致GDB变得非常慢。你可以尝试使用GDB的一些调试优化选项，或者尝试使用其他的调试工具，比如LLDB或Visual Studio的调试器。
【 在 z16166 的大作中提到: 】
: 起因是：
: 下面的程序debug版本跑着没问题，但是release版本那条log会反复打印，而且gdb里能看到反复创建LWP线程。
: 有的时候gdb很卡，表现就是按了ctrl + c后很久才反应，断下来显示提示符。
: ...................
--
FROM 114.94.8.* - 是一个同事搞的代码，我看到编译警告后，让他改，他改了还没提交，
然后我用没改的代码去查另外一个问题，遇到了这个UB问题的现象，折腾了半天。
这里有一个类似的例子，g++比较极端，gcc略好点(要加一句#include <stdbool.h>才能用gcc编译)：
https://pvs-studio.com/en/blog/posts/cpp/0917/
C++标准里的这句，其实有点误导，前半句让人以为是会返回随机值，后半句定性为UB：
Flowing off the end of a function is equivalent to a return with no value; this results in undefined behavior in a value-returning function.
【 在 iconquer 的大作中提到: 】
: 文心的回答：
: 您的问题涉及到了C++的未定义行为（Undefined Behavior）以及GCC编译器在Release版本下的优化问题。
: 首先，C++标准规定，如果一个函数没有显式的返回语句，且函数的返回类型不是void，那么这个函数的返回值是未定义的。未定义行为是一种编译器不会进行任何错误检查的特殊行为，它可能会导致任何结果，包括看似合理的结果。
: ...................
--
修改:z16166 FROM 221.218.160.*
FROM 221.218.160.* - clang也是这个行为。貌似回复的人大多数不认为是编译器bug
https://stackoverflow.com/questions/68591212/c-for-loop-is-optimized-into-endless-loop-if-function-return-statement-is-mis
【 在 ylh0315 的大作中提到: 】
: 陷入死循环是不对的，应该是个BUG
--
FROM 221.218.160.* - 但gcc和clang处理这个UB，就是会搞出来死循环。
而且有编译警告，所以没看到有人说这是编译器的bug
【 在 ylh0315 的大作中提到: 】
: 我看过很多函数的汇编码，没有发现不返回就死循环的。
--
FROM 221.218.160.* - 那你的眼睛很年轻
我是看不了一片白光的屏幕了，干眼症特容易被这个刺激
【 在 ylh0315 的大作中提到: 】
: 真累眼睛。
: 用gcc -S 看看生成的汇编码。
--
FROM 221.218.160.* - 遇到过。。。
【 在 z16166 的大作中提到: 】
: 起因是：
: 下面的程序debug版本跑着没问题，但是release版本那条log会反复打印，而且gdb里能看到反复创建LWP线程。
: 有的时候gdb很卡，表现就是按了ctrl + c后很久才反应，断下来显示提示符。
:
: 注释掉创建线程的那句后，会崩在log语句里调用\_\_l
: ..................
--
FROM 101.226.154.* - 理论上不是bug，实际上也就是因为这些编译器开源免费可以随便搞，大家才捏着鼻子凑合用。
【 在 z16166 (Netguy) 的大作中提到: 】
: clang也是这个行为。貌似回复的人大多数不认为是编译器bug
: https://stackoverflow.com/questions/68591212/c-for-loop-is-optimized-into-endless-loop-if-function-return-statement-is-mis
:
: 【 在 ylh0315 的大作中提到: 】
--
FROM 183.179.53.* - 因为UB产生的任何现象都不应该被当成BUG吧……
【 在 fanci 的大作中提到: 】
理论上不是bug，实际上也就是因为这些编译器开源免费可以随便搞，大家才捏着鼻子凑合用。
【 在 z16166 (Netguy) 的大作中提到: 】
: clang也是这个行为。貌似回复的人大多数不认为是编译器bug
: https://stackoverflow.com/questions/68591212/c-for-loop-is-optimized-into-endless-loop-if-function-return-statement-is-mis
:
: 【 在 ylh0315 的大作中提到: 】
--
FROM 123.118.110.14 - 。。。
现在不返回都不报错了吗
--
FROM 43.226.236.*