Libboost :: resolver收到了SIGABRT

时间:2018-06-13 09:09:58

标签: c++11 networking boost-asio

我发现以下代码使用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)

主机名是正确的,以及localhost的IP地址。我知道计算机上有多个接口,并且查询可以返回任意数量的接口,但我没有看到连接到计算机的其他两个接口。我还将添加 ifconfig 的输出。

但是,我的问题是关于“free():invalid size”位。 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

2 个答案:

答案 0 :(得分:2)

除了@andreee回答之外,始终使用-Wall -Wextra -Werror编译代码,以便在编译时检测到这些令人讨厌的错误。没有理由不使用这些标志。

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

答案 1 :(得分:1)

您触发了一个令人讨厌的未定义行为(UD)案例,最终导致程序中出现SIGABRT。在9.6.3 [stmt.return]

  

在构造函数,析构函数或具有cv void返回类型的函数的末尾流动,相当于没有操作数的返回。   否则,流出除main之外的函数的末尾会导致未定义的行为。

从技术上讲,在函数返回后,您的代码可能会发生任何。在大多数情况下,没有任何事情发生,每个人都会感到高兴,因此人们通常会忽略no return statement in function returning non-void之类的警告。

现在你明白为什么这可能是非常坏事。如果您将返回类型设置为void而不是std::string,或者如果执行返回一些字符串,则程序不会再崩溃。

虽然gcc生成的代码似乎产生segfaultabort(取决于版本),但是clang生成的代码将发出illegal instruction。如果更改返回类型,两个编译器都可以正常工作。为了更加困惑,请使用gcc 4.9.x;这里是你的代码just works fine,尽管是UB。

这段代码是 undefined 行为的真正甜心,可能会让您的应用程序陷入困境。