NoBlockConnect() bug in v2.6.3?

[dpursell]

On a MOD5234 with NBEclipse v2.6.3 I ran into a bug where sockets that failed to connect would never be released by the standard close() functions. After a few seconds, I would run out of sockets and the program would fail. This only happened with sockets that failed to connect, those that connected successfully seemed to close without issue.

I don't know enough about the networking library to figure out the exact cause of the bug, but there seem to be two things that the blocking connect() function does that are not done when using NoBlockConnect() + close():
1. Sets the TCP_USER_CLOSED flag in gpflags (But I think this is done in _Socket_Private_close() further down the call stack so it doesn't seem like an issue)
2. Calls DoClose(TCP_ERR_TIMEOUT) - when using the standard close() function it's going to be DoClose(TCP_ERR_NORMAL) instead

I ended up adding my own function to tcp.cpp to do these things, and it seems to work, but I prefer not to modify the system files if not absolutely necessary. Is there any existing functionality I should be using to close these sockets?

For reference, here is my function

Code: Select all

void NoBlockClose(int fd)
{
  int sl = fd - TCP_SOCKET_OFFSET;
  register PSOCKET ps = sockets + sl;
  
  ps->gpflags |= TCP_USER_CLOSED;
  ps->DoClose( TCP_ERR_TIMEOUT );
}

Also, should I lock TCP_critical_section at the beginning of the function? The connect() function doesn't seem to so I wasn't sure if it was necessary in this case.

Thanks,
David

[dciliske]

There have been some changes to tcp cleanup with closing issues introduced with the NoBlockConnect call in the latest version of the NNDK (2.6.4).

I'll poke Paul to get the full version of the changes/what you should do.