调用zmq_poll()为何触发zmq_abort()？（ZMQ 4.2.2版本）

Let’s break down why your program is crashing with zmq_abort() at that seemingly odd line in the socket_poller_t destructor, and walk through how to fix it.

First: Why the line number looks off #

The stack trace points to line 54 of socket_poller.cpp—just the start of the ~socket_poller_t() function definition—with no direct zmq_abort() call here. This is almost always caused by compiler optimization (like -O2 or higher) skewing debug line numbers. The actual crash is happening inside a sub-operation of the destructor, such as:

• Destruction of internal member variables (e.g., poller state structures, item lists)
• Cleanup logic triggered by the destructor (like stopping background threads or deallocating resources)

Key Causes to Investigate #

Looking at your stack trace, there are critical red flags to prioritize:

1. Invalid items_ pointer in zmq_poller_poll #

Your stack shows:

#5 0x00007f12ce917e14 in zmq_poller_poll (timeout_=, nitems_=2, items_=0x1) at ../zeromq-4.2.2/src/zmq.cpp:854

The items_ parameter is 0x1—a clearly invalid pointer (it points to memory address 1, which can’t be a valid zmq_poller_item_t array). This corruption will cause ZMQ’s internal code to hit an assertion failure, which directly triggers zmq_abort().

Common ways this happens:

• Stack overflow in your code overwriting the items_ pointer value
• Passing an uninitialized variable as the items_ parameter
• Memory corruption from other parts of your program affecting this pointer

2. Thread safety violations #

ZMQ 4.2.2’s socket_poller is not thread-safe. If one thread is calling zmq_poller_poll while another calls zmq_poller_destroy on the same poller instance, this will corrupt internal state and almost certainly lead to an abort. Your stack shows zmq_poller_destroy being called immediately after zmq_poller_poll, which suggests a possible race condition or incorrect lifecycle management.

3. Double destruction or invalid poller state #

Calling zmq_poller_destroy more than once on the same poller, or accessing the poller after it’s been destroyed, will cause memory corruption that leads to zmq_abort() during cleanup.

Debugging Steps to Fix This #

1. Disable compiler optimization and recompile
   Build your program with -O0 to get accurate debug line numbers. This will show you exactly which line inside ~socket_poller_t() or its subroutines is triggering the abort (likely a failed zmq_assert() call).

2. Validate your zmq_poller_poll parameters
   Audit the code where you call zmq_poller_poll:

   • Ensure the items_ pointer points to a valid, properly initialized array of zmq_poller_item_t structures
   • Verify nitems_ matches the actual length of the items_ array
   • Check for buffer overruns or stack overflow issues in the code surrounding this call (these can corrupt pointer values)

3. Audit poller lifecycle and thread usage

   • Make sure you’re not calling zmq_poller_destroy until all in-progress zmq_poller_poll calls on that instance have completed
   • If using threads, add synchronization (like mutexes) around poller operations, or use a separate poller per thread
   • Confirm you’re not destroying the same poller multiple times

4. Inspect the assertion failure
   zmq_abort() is almost always triggered by a failed zmq_assert() macro. To see what assertion failed:

   • With -O0 enabled, use GDB to print the errmsg_ parameter in zmq_abort() (it should contain the specific assertion message)
   • Alternatively, temporarily modify ZMQ’s err.cpp to log errmsg_ to stdout before calling abort()

内容的提问来源于stack exchange，提问作者user2373682