When starting an sctp client with gdb, I experience a connect failure (-1 is returned), with errno 106 (Transport endpoint is already connected). If I then cat /proc/net/sctp/assocs, I see the connection and I see the successful handshake on wireshark. If I ignore the connect failure, and pretend I'm actually connected, I can send and receive packets without any trouble. The same client application, run not-under-gdb, does not exhibits the issue and the connect returns 0.
Does the application in question have any signal handlers that are registered with SA_RESTART set? My first thought would be that a call to sctp_connect might be aborted due to EINTR after the association has been set, but the syscall layer restarts the connect without the application knowing, leading to an EISCONN error even though is managed to connect. If thats the case, not sure what the solution would be yet, but I image we have to catch or block EINTR somewhere in sctp_primitive_ASSOCIATE, or deeper in the state machine.
I could not find any registered signal handlers by the application (I also smelled that signals could be involved, but did not find any evidence).
can you attach a stap script to sctp_connect in the kernel, and see if its getting called multiple times?
Or you could try: echo -n "module sctp func sctp_connect +p" > /sys/kernel/debug/dynamic_debug/control and try the gdb app. There should be an entry in the log for ever attempt call sctp_connect.