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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Valgrind disagree with pop_front() on received zmqpp::message #204

Open
pavel-orekhov opened this issue Jan 23, 2018 · 2 comments
Open

Valgrind disagree with pop_front() on received zmqpp::message #204

pavel-orekhov opened this issue Jan 23, 2018 · 2 comments

Comments

@pavel-orekhov
Copy link

When I call pop_front() on message after sock.receive() valgrind starts to worry.
I use 4.2.0+ version at intel64 (ubuntu 17.10)
Please confirm the bug.

commit 818f9c3 (HEAD -> develop, origin/develop, origin/HEAD)
Author: Ben Gray [email protected]
Date: Fri Nov 3 11:29:06 2017 +0000
shifted tests to use last_endpoint to avoid port collisions (#203)
commit f8ff127 (tag: 4.2.0)

A sample is here:
popfront.cpp.txt

@pavel-orekhov pavel-orekhov changed the title Valgrind disagree with pop_front() on reveived zmqpp::message Valgrind disagree with pop_front() on received zmqpp::message Jan 24, 2018
pavel-orekhov pushed a commit to pavel-orekhov/zmqpp that referenced this issue Jan 29, 2018
* add message::operator<< for message (AKA append) and for frame
* tests for new methods
* fix indent
@pavel-orekhov
Copy link
Author

pavel-orekhov commented Feb 1, 2018

I found a sentence:

If you do use zmq_msg_recv(), always release the received message as soon as you're done with it, by calling zmq_msg_close().

Queue to check it with pop_front()

@rcane
Copy link
Contributor

rcane commented Mar 1, 2018

The problem here is a bug in the move assignment operator of the frame class.

frame& frame::operator=(frame&& other)
{
    zmq_msg_init( &_msg );   <-- this line needs to go
    zmq_msg_move( &_msg, &other._msg );
    std::swap( _sent, other._sent );

    return *this;
}

The call to zmq_msg_init() at the beginning clears the zmq_msg_t object without closing it. Since zmq_msg_move() does that closing on the supplied _msg the solution is simple: just remove the zmq_msg_init() line.

Btw, the reason why valgrind is complaining about message::pop_front() is that this method erases the first element of the message from a std::vector<frame>. When doing this the vector needs to move all remaining frames thereby leaking memory for each of them.

rcane added a commit to softvise/zmqpp that referenced this issue Jun 15, 2023
The zmq_msg_init() at the beginning created a new message overwriting
the handle of the old message. But this old message was not closed
leaving a memory leak behind. Instead of closing the existing handle
explicitly we can simply remove the init call because zmq_msg_move()
does the closing of the old message on its own.

see zeromq#204
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

2 participants