Socket server crashes if the socket is closed by the remote host before stream_socket_accept is called

[krageon]

If the remote host closes the socket early, this raises an E_WARNING when calling stream_socket_accept. This turns into an exception (depending on your configuration).

Seeing as the output of this function is checked (false or something else) exactly one line after it is called, it makes sense to suppress the warnings and use the existing handling for this case.

[clue]

If the remote host closes the socket early, this raises an E_WARNING when calling stream_socket_accept.

We have yet to find a way to reproduce the issue you're seeing. I've given this several attempts, but failed to raise an error here so far.

Perhaps https://3v4l.org/LlXo1 could be a good starting point.

This turns into an exception (depending on your configuration).

I'm not sure I follow? If we manage to reproduce this, then this will raise an (uncaught) E_WARNING only and will then raise an error event as documented.

Seeing as the output of this function is checked (false or something else) exactly one line after it is called, it makes sense to suppress the warnings and use the existing handling for this case.

Agreed, we should not raise any warnings whatsoever.

[krageon]

It raises the E_WARNING immediately, the error event handler will not happen (this is because that event gets raised because of some function output, but the warning pops up as soon as the function executes).

I'll try and see if I can get a good simple case going tomorrow. As I said on the pull request, I've only managed to reproduce the issue using HAProxy's tcp-check so far.

[clue]

It raises the E_WARNING immediately, the error event handler will not happen (this is because that event gets raised because of some function output, but the warning pops up as soon as the function executes).

I agree that this warning shouldn't be raised to begin with and we should address this. However, this warning alone should not interfere with the error event handler and should not stop script execution. In other words, we have yet to reproduce how this "crashes".

For the reference, the accept(2) man pages list some error conditions which should help in providing a test script.

[WyriHaximus]

@krageon can you share how you can reproduce it? I'de like to get this thing resolved so I'm looking into making a test for it

[krageon]

A little while ago I sat down with a colleague of mine in an attempt to replicate a simpler version of the environment that produces this, but we can't seem to do it outside of where it actually occurs. At this point I'm more inclined to say it's not necessarily a problem with the library, but with where I'm using it.

[cboden]

fixed in #23