Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assert in zmq::object_t::process_command (src/object.cpp:170) #4649

Open
Joacchim opened this issue Jan 8, 2024 · 0 comments
Open

Assert in zmq::object_t::process_command (src/object.cpp:170) #4649

Joacchim opened this issue Jan 8, 2024 · 0 comments

Comments

@Joacchim
Copy link

Joacchim commented Jan 8, 2024

Hello,

First of all, thanks for the great work on this library. I know it's not new, and quite popular, but you guys deserve the thanks nonetheless 馃挐.
This issue is, depending on your answers, either a call for help (understanding what we do wrong), or a bug report 馃し.

My team is using ZMQ behind its python3 binding, in order to handle communications between multiple processes (python's multiprocessing Process). While it's working fine most of the time since we've set it up (during 2023), we've recently encountered an odd assertion within what I believe to be the ZMQ code, since the file path seems to match, and one of the remaining processed logged ZMQ errors right after the one that encountered the assert went down.

Connection model: multiple 1-to-1 Dealer/Router connections between multiple processes.
Usage of threads: Yes

  • main thread to serve the API via ZMQ (thus, as a Router)
  • one thread to update internal state based on the communications with a dedicated set of peers, via ZMQ too (as a Dealer this time).

Alas, we did not have CoreDumps activated on that server, and did not see the issue reproduced since (not so long ago, it might at some point, though).

From what I understand of the code, the assert could be related to the command_t.type field being set to command_t::done. As I am clearly not an experienced ZMQ user, I lack the context allowing me to understand what could have happened.

Environment

  • libzmq version (commit hash if unreleased): Debian package version: 4.3.4-1
  • Language binding: Python (Debian package python3-zmq 20.0.0-1)
  • OS: Debian 11 (bullseye)

Minimal test code / Steps to reproduce the issue

Sorry, we've only encountered the issue once, and I lack information about the exact issue to be able to slap together a reproduction case.

What's the actual result? (include assertion message & call stack if applicable)

Message caught by our systemd unit's journal:

Assertion failed: false (src/object.cpp:170)

What's the expected result?

Probably having a ZMQ error that we could handle in the python code somehow ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant