Libboost :：resolver已接收SIGABRT

Question

我找到了下面的代码来使用libboost获取本地IP地址。我用的是libboost 1.65。

#include <iostream>
#include <boost/asio.hpp>

std::string getHostIP ()
{
    using boost::asio::ip::tcp;    

    boost::asio::io_service io_service;
    tcp::resolver resolver(io_service);
    std::cout << boost::asio::ip::host_name() << std::endl;
    tcp::resolver::query query(boost::asio::ip::host_name(), "");
    tcp::resolver::iterator iter = resolver.resolve(query);
    tcp::resolver::iterator end; // End marker.
    while (iter != end)
    {
         tcp::endpoint ep = *iter++;
         std::cout << ep << std::endl;
    }
}

int main() {
    getHostIP();
}

我目前得到的输出是

daniel-XVirtualBox
127.0.1.1:0
free(): invalid size
Aborted (core dumped)

主机名正确，本地主机的IP地址也是正确的。我知道计算机上有多个接口，该查询可以返回任意数量的接口，但我没有看到连接到计算机的另外两个接口。我还将添加ifconfig的输出。

但是，我的问题是关于"free()：无效大小“位。GDB还说：

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

***Backtrace***
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007ffff705a801 in __GI_abort () at abort.c:79
#2  0x00007ffff70a3897 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff71d0b9a "%s\n")
    at ../sysdeps/posix/libc_fatal.c:181
#3  0x00007ffff70aa90a in malloc_printerr (str=str@entry=0x7ffff71ceda0 "free(): invalid size") at malloc.c:5350
#4  0x00007ffff70b1e2c in _int_free (have_lock=0, p=0x7ffff7de5990 <_dl_init+864>, av=0x7ffff7405c40 <main_arena>)
    at malloc.c:4161
#5  __GI___libc_free (mem=0x7ffff7de59a0 <_dl_fini>) at malloc.c:3124
#6  0x0000555555559111 in main () at boost_gethostname.cpp:22

我错过了一个boost::asio::io_service的清理程序吗？应该停止解析器吗？另外，为什么我看不到计算机上的所有接口？

谢谢!

ifconfig: 
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.2.15  netmask 255.255.255.0  broadcast 10.0.2.255
        inet6 fe80::ecd6:f288:3b03:d8cf  prefixlen 64  scopeid 0x20<link>
        ether 08:00:27:37:63:98  txqueuelen 1000  (Ethernet)
        RX packets 114124  bytes 111705475 (111.7 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 42644  bytes 3732986 (3.7 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp0s8: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.10.11.221  netmask 255.255.255.0  broadcast 10.10.11.255
        inet6 fe80::3aa2:ecbd:5702:2ab4  prefixlen 64  scopeid 0x20<link>
        ether 08:00:27:a6:44:ce  txqueuelen 1000  (Ethernet)
        RX packets 194194  bytes 24826176 (24.8 MB)
        RX errors 0  dropped 7354  overruns 0  frame 0
        TX packets 1189  bytes 127853 (127.8 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 912  bytes 76283 (76.2 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 912  bytes 76283 (76.2 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Answer 1

您已经触发了一种令人讨厌的未定义行为(UD)，它最终导致程序中的SIGABRT。在9.6.3 [stmt.return]中

从构造函数、析构函数或具有cv空返回类型的函数的末尾流出，等同于不带操作数的返回。否则，除主函数之外的函数结束时，会产生未定义的行为。

从技术上讲，在函数返回之后，代码几乎可以发生任何事情。在大多数情况下，什么都不会发生，每个人都会很高兴，因此人们大多忽视像no return statement in function returning non-void这样的警告。

现在，你可以看到为什么这会是一件非常糟糕的事情。如果将返回类型设置为void而不是std::string，或者如果确实返回一些字符串，则程序不再崩溃。

gcc生成的代码似乎会生成分段故障或中止 (取决于版本)，而clang生成的代码则会发出非法指令。如果更改返回类型，这两个编译器都做得很好。对于更多的困惑，请以gcc 4.9.x为例；这里是您的代码工作得很好，尽管有UB。

这段代码是一个真正可爱的未定义行为的馅饼，它会使您的应用程序陷入困境。

Answer 2

除了@andreee答案之外，总是使用-Wall -Wextra -Werror编译您的代码，以便在编译时检测到这些令人讨厌的错误。没有理由不使用这些旗帜。

在我的makefile中，我通常使用bash扩展-W{all,extra,error}。