Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: SFML2: UdpSocket::Receive() allocating memory more and more  (Read 4280 times)

0 Members and 1 Guest are viewing this topic.

Randati

  • Guest
SFML2: UdpSocket::Receive() allocating memory more and more
« on: October 02, 2010, 09:26:26 pm »
I have a problem using sf::Packets with sf::UdpSocket::Receive(). Every time I call the function it allocates more and more memory until it hits 0.5 GB and crashes. Here's a minimal example.
Code: [Select]
#include <SFML/Network.hpp>

int main() {
sf::UdpSocket socket;
socket.SetBlocking(false);
socket.Bind(54354);

sf::IpAddress client_ip;
unsigned short client_port;
sf::Packet packet;

while (true) {
socket.Receive(packet, client_ip, client_port);
}
}


Without Packets it works just as it should. It doesn't allocate more memory with every call.
Code: [Select]
char buffer[1024];
std::size_t received = 0;

while (true) {
socket.Receive(buffer, sizeof(buffer), received, client_ip, client_port);
}

Internally sf::UdpSocket::Receive() grows the size of sf::UdpSocket::myPendingPacket.Data every time.

Am I doing something wrong here or is this maybe a bug?
I'm using the latest SFML 2.0 snapshot.

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
SFML2: UdpSocket::Receive() allocating memory more and more
« Reply #1 on: October 03, 2010, 08:43:37 am »
Yes, you're doing something wrong.

What is the differences between the two codes?
In the first one you use a 'dynamic size' container to receive data into. In the second one you use a static one.

That's why in the first example your App is taking more and more memory. Now you may wonder how to use Packet without this bad growing and growing thing. You have simple to clear it. Check out the tutorial or the doc to find the right function.
SFML / OS X developer

Randati

  • Guest
SFML2: UdpSocket::Receive() allocating memory more and more
« Reply #2 on: October 03, 2010, 05:08:41 pm »
I can't find any function that would clear the socket.
The problem happens only in non-blocking mode when the socket is not receiving anything. Then UdpSocket::Receive returns NotReady. If it received something, it would return Done and clear itself.
Any tutorial or doc is not really helping. Maybe I'm looking from wrong places.

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
SFML2: UdpSocket::Receive() allocating memory more and more
« Reply #3 on: October 03, 2010, 05:41:11 pm »
Not clear the socket but the packet. What happens if you use http://www.sfml-dev.org/documentation/2.0/classsf_1_1Packet.htm#3a7a30fb7a39e59df0cbd773756f60da after each receive ?
SFML / OS X developer

Randati

  • Guest
SFML2: UdpSocket::Receive() allocating memory more and more
« Reply #4 on: October 03, 2010, 05:46:41 pm »
It doesn't help. The packet is empty already, because the socket is not receiving anything. Also UdpSocket::Receive() clears the packet before using it.
The packet's size is always 0, but UdpSocket::myPendingPacket.Data is growing.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
SFML2: UdpSocket::Receive() allocating memory more and more
« Reply #5 on: October 03, 2010, 06:29:52 pm »
How do you send data on the other side?
Laurent Gomila - SFML developer

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
SFML2: UdpSocket::Receive() allocating memory more and more
« Reply #6 on: October 03, 2010, 06:38:11 pm »
<snip>crossposting
SFML / OS X developer

Randati

  • Guest
SFML2: UdpSocket::Receive() allocating memory more and more
« Reply #7 on: October 03, 2010, 06:38:19 pm »
I'm not sending anything yet. Only the server is running. It crashes in a couple seconds if nothing is send and I don't slow the loop at all.

OS is 64bit Windows 7. Not OS related though, same happens on Ubuntu.

Randati

  • Guest
SFML2: UdpSocket::Receive() allocating memory more and more
« Reply #8 on: October 16, 2010, 08:31:42 pm »
Revision 1583 fixed this, thank you!