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

Author Topic: Just another funny bug  (Read 24121 times)

0 Members and 2 Guests are viewing this topic.

zac

  • Jr. Member
  • **
  • Posts: 60
    • View Profile
Just another funny bug
« on: January 20, 2009, 06:48:01 pm »
Hey - I seem to be receiving a SIGPIPE from within SocketTCP::Send - it means that you try to write to a socket without a reader - the default reaction is to terminate the application.
This is what happens to my server if the client kills the connection before everything is ready. At first, a FIN packet is sent, but the server does not react to it properly. Then, when the server is trying to write again (because Send did not return Socket::Error but Socket::NotReady from within Send), it really sends the data (normal PSH packet), but all it gets is the RST packet from the obviously already closed client socket.
And then, the server process receives a "SIGPIPE" signal and is terminating.

I'm working with Non-Blocking sockets.

A possible workaround:
Add "signal(SIGPIPE,SIG_IGN);" to the SocketHelper initialisation for Linux.
I would also suggest to test the return value when you are sending the packet size in SocketTCP::Send(const sf::Packet&).

zac

  • Jr. Member
  • **
  • Posts: 60
    • View Profile
Just another funny bug
« Reply #1 on: January 20, 2009, 11:38:25 pm »
Maybe this will help:

Linux.die.net:
When writing onto a connection-oriented socket that has been shut down (by the local or the remote end) SIGPIPE is sent to the writing process and EPIPE is returned. The signal is not sent when the write call specified the MSG_NOSIGNAL flag.

Maybe you should use this flag?

Ceylo

  • Hero Member
  • *****
  • Posts: 2325
    • View Profile
    • http://sfemovie.yalir.org/
    • Email
Just another funny bug
« Reply #2 on: January 21, 2009, 12:39:38 am »
...or handle the signal.
Want to play movies in your SFML application? Check out sfeMovie!

zac

  • Jr. Member
  • **
  • Posts: 60
    • View Profile
Just another funny bug
« Reply #3 on: January 21, 2009, 12:20:22 pm »
Yes, but I like the solution with the flag best. It is easy to test if this flag is available and it doesn't take the user of the library the freedom to handle the signal himself...