在使用zeromq 退出的时候还遇到一点坑,对于服务deaman(守护进程)化的进程可能会遇到这个问题。

现象:

这个问题导致的现象是服务一旦关闭(stop),就会 core dump,core dump 的信息如下。意思大概是使用了无效的描述符。

img

(gdb) bt
#0 0x00007f522e2le387 in raise () from /lib64/libec.so.6
#1 0x00007f522e21fbb8 in abort () from /lib64/libec.so.6
#2 0x00000000004d5909 in zmq::zmq_abort (errmsg_errmsg_@entry=0x7f522e37025f "Bad file descriptor") at src/err.cpp :88
#3 0x00000000004d5242 in zmq::epoll_t::add_fd_(this=0x1b25520, fd_efd_@entry=15, events_events_@entry=0x1b28580) at src/epoll.cpp:100
#4 0x00000000004e42e2 in zmq::socket_base_t::start_reapiing (this=0x1b28140, poller_=<optimized out>) at src/socket_base.cpp:1465
#5 0x000000000004ela63 in zmq::reaper_t::process_reap (this=0xlb21580, socket_=<optimized out>) at src/reapercpp:133
#6 0x000000000004ele7c in zmq::reaper_t::in_event (this=0x21b21580) at src/reaper.cpp:104
#7 0x00000000004d508e in zmq::epoll_t::loop (this=0x1b255520) at src/epoll.cpp:206
#8 0x00000000004f0d45 in thread_routine (arg_=0x1b255778) at src/thread.cpp:257
#9 0x00007f522f23dea5 in start_thread () from /lib64/libpthread.so.0
#10 0x00007f522e2e6b0d in clone () from /lib64/libc.so.6

产生的原因:

我们服务的 Server 是个 static Instance 单例,在 Server 里默认分配内存的方式声明了 zeromq 的 ContextsocketServer 单例创建的时候,就会创建好 Context 和 socket。


class Server
{
	....
  private:
	  zmq::context_t m_context;
    zmq::socket_t  m_socket;
}

在启动服务后,会判断是否需要守护化(daemon化),如果需要,就会 fork 进程并创建守护进程,主进程退出。

正是主进程退出时没有调用 Context 的销毁函数,导致子进程退出时,虽然处理了 Context 的销毁,但是主进程创建的 Context 却没有调用销毁函数,导致和 zeromq 内部线程还在访问失效的描述符,从而出现了 core dump。这里需要解释一下,在 fork 时,子进程也会拷贝父进程的 static 数据。

下面是关于 fork 后父进程和子进程 static 内存数据的介绍:

在 fork 函数调用时,父进程的内存会被复制到子进程中,包括 static 数据的内存。这意味着子进程也会拥有与父进程相同的 static 数据,但是它们是相互独立的。如果在父进程或子进程中修改了 static 数据,则不会影响另一个进程中的 static 数据。

补充一段static类析构调用时机的介绍:

对于在 C++ 中声明为静态变量的类对象,其析构函数会在程序结束时被调用。具体来说,静态对象的析构函数会在程序退出 main 函数后,动态库被卸载之前,以及进程终止时被调用。

静态对象的析构顺序和构造顺序相反。也就是说,先构造的静态对象后被析构,后构造的静态对象先被析构。这一点需要注意,因为不同的静态对象之间可能存在相互依赖的关系,因此析构顺序可能会对程序的正确性产生影响。

需要注意的是,如果静态对象是在动态链接库中定义的,则其析构函数会在动态链接库被卸载之前被调用。因此,如果静态对象依赖于动态链接库中的其他对象或者库资源,需要注意析构顺序的问题,避免出现资源泄漏或者悬挂指针等问题。

另外,对于静态对象的构造函数和析构函数,需要确保它们不会产生任何异常,否则可能会导致静态对象无法正确地被构造或析构,从而产生未定义行为。

解决方法:

m_contextm_socket 声明为指针类型,在守护化后的 Init 调用中进行初始化。

  private:
	  zmq::context_t * m_context;
    zmq::socket_t  * m_socket;

这也给我们一些启示,对于类成员是第三方类,最好声明为指针,在初始化函数里调用初始化。

内容来源于网络如有侵权请私信删除

文章来源: 博客园

原文链接: https://www.cnblogs.com/listenwind666/p/17239467.html

你还没有登录,请先登录注册
  • 还没有人评论,欢迎说说您的想法!

相关课程