-
Notifications
You must be signed in to change notification settings - Fork 265
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixed sockindex left with non-default value when connection fails. #176
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.