-
Notifications
You must be signed in to change notification settings - Fork 13
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
Compiler warning when "delete"ing a client instance #21
Comments
It seems to me an explicit virtual destructor is needed. The destructor should close the connection and free the socket, if used. |
That would be great, I just added an empty function
in WiFiSpiClient.cpp as well as
in WiFiSpiClient.h and it prevents the warning (not sure if "virtual" is correct here), but you are right, the connection should be closed and the socket freed as well. Thanks for looking into this, looking for the patch! |
no. the WiFiClient of Arduino net API should not close the connection if destroyed. (server.available() returns a copy, some function can take it in parameter as a copy) WiFiClient should be only a pointer to internal representation. In ESP8266WiFi library the WiFiClient does it with ClientContext. All objects of the WiFiClient class for the same TCP connection must see the same state of the connection including for example buffer and count of data available. I recently found out that the WiFiClientSecure for BearSSL in esp8266 WiFi library doesn't work on this principle and the developers fixed it immediately with a not trivial change. In this library the WiFiClient should only point to WiFiClient object on firmware side as it is in Ethernet library and other WiFi libraries which are only remote API of firmware. |
Thanks Juraj! Line 62 in ec4a9d4
But it seems to me, there should be a housekeeping after destroying the WiFiClient that is not linked to the server socket as there would be no chance to connect to the socket and close it afterwards. |
Thanks, that seems to correspond with what I found here: Does "server code" here mean the "WiFiSpiEsp" code/library? Or code inside the ESP8266-SDK? |
The library can be used to run a TCP client or server. |
Jiri, this is my PR to esp8266 WiFi library, which contains a discussion about correct Arduino Server and Client implementation |
Juraj, the problem with multiple WiFiClient objects for one connection is constrained to TCP server functionality, right? |
it is valid for arduino code to copy the Ethernet/WiFiClient object. as assignment or as function parameter by copy (parameter type without & or *). this is not (ab)used widely, but can occur. I can't now find an example. I checked some libraries which work with Client and they all use
is valid and works. it looks crazy for a C++ programmer and is not efficient (compiler optimizes it to some level) |
I see. The problem is quite bigger than I originally thought.
Definitely, WiFiClient destructor should not close the connection. |
index to an array on the ESP side. See https://github.com/JiriBilek/WiFiSpiESP/blob/018349de89ef63ff8f4d01792f9bfda29b4c9eca/WiFiSPIESP/WiFiSPICmd.h#L39 and next few lines It must be synchronized between the protocol (SPI) client and server. Edit: maybe you are asking the meaning of the command |
sorry I deleted the comment to not open a new problem. I don't want to look into source code of your library now, but shouldn't the firmware return 'sock' index of the current client. there can be more then one client connected. and next problem is that, the esp8266 WiFiServer available() implementation doesn't comply with Arduino. |
@fredlcore : weird thing: the following code compiles without error. Am I missing something? Compiled with arm-none-eabi-gcc\4.8.3-2014q1
|
Ah, ok! The difference to my code is that I don't have the |
Reason is only one: pointer required only 2(4) bytes RAM when we won't need network connection. As usually it is not life critical for Due but for Mega. In our code we use pointer.
|
you have a pointer. max_cul is a pointer. it would not compile if it wouldn't @dukess, repeated heap allocation fragments the heap and there is no memory management to defragment it. |
Sorry, I looked further down in our code where it says @JiriBilek: Hm, if you had a gcc version prior to 4.7, the warning was apparently not shown, see here: |
...and yes, that seems to be the case: If I compile your code snippet, I get the following warning:
|
@fredlcore Now, I tested compilation under xpack-arm-none-eabi-gcc/9.2.1-1.1, got warning about deprecated boolean type but nothing more. Could you please post your compiler version? |
arm-none-eabi-g++ (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 7.2.1 20170904 (release) [ARM/embedded-7-branch revision 255204] |
With |
I'm nowhere near being a C++ guru, but maybe this is helpful? |
Solves compiler warning about non existent virtual destructor for derived classes. #21
Fixed: 28f491e |
Great, thanks! |
@JAndrassy Yesterday I tried turning the connection on and off multiple times to see if there would be memory leaks. Maybe I was lucky, but the size of free memory did not decrease. |
@JiriBilek thank you! |
@ everybody: you're welcome @dukess It's great you have no problems in heap fragmentation. |
@JiriBilek Thanks for the explanation. I think that in our project, we should not be too afraid of fragmentation: configuration changes (enabling/disabling modules) are rare, and we can send the controller to restart after saving the configuration. The main purpose of using pointers is to save memory when the module is not in use. |
BTW: the same warning also occurs with the official Ethernet 2.0 library... |
We have two way: add destructor independently or ask developers. |
I opened a pull request, but this is no longer the scope of this issue here, just wanted to mention that this seems to be a more general problem... |
The following code results in the warning below:
Is there a way to prevent this warning?
The text was updated successfully, but these errors were encountered: