-
Notifications
You must be signed in to change notification settings - Fork 267
Fixed sockindex left with non-default value when connection fails. #176
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
base: master
Are you sure you want to change the base?
Conversation
Memory usage change @ 4519a30
Click for full report table
Click for full report CSV
|
Any update? I see no reason for not including this in the next release. |
Could we please get this PR merged? I submitted it more than 2 years ago, and the issue has been separately raised in a later PR #208. |
47be3d9
to
d0da988
Compare
Memory usage change @ d0da988
Click for full report table
Click for full report CSV
|
I have just rebased my PR branch. @PaulStoffregen Since you wrote the code, could you take a look a tell us if the suggested change makes sense? I would like to point out that the original code in 2013 handled the failure in a similar way. See below: Ethernet/src/EthernetClient.cpp Line 58 in 1291aaa
|
I believe I have found an issue.
When a connection established through
EthernetClient::connect
fails, thestat
variable will have a value ofSnSR::CLOSED
causing the function to return immediately with a value of0
without resetting thesockindex
variable to the defaultMAX_SOCK_NUM
.The problem manifests itself at least when the following chain of events happen:
Object A holds an instance of
EthernetClient
. It tries to establish a TCP connection troughEthernetClient::connect
which fails because the port is not open on the server. Its instance is left withsockindex
at0
.Object B performs a UDP exchange (
EthernetUDP::begin
,EthernetUDP::beginPacket
,EthernetUDP::write
,EthernetUDP::endPacket
,EthernetUDP::parsePacket
, read but noEthernetUDP::stop
yet). It is attributedsockindex
of0
.Object A tries again to connect, his instance still has a
sockindex
of0
, which leads to chaos because it's referencing a completely different socket.