Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
riataman
@riataman
if you keep the binary you could compare thosre
stil the source can be the same, but the binary different
brutzler
@brutzler
same source, different binary? thats the dead end...
riataman
@riataman
anyway, there's no easy way to do it
the easy way is to incorporate a Serial.print("Version v1.2") to your sketch
and remember to change it everytime you make changes
brutzler
@brutzler
I thought the same way. Compile the sources and compare the binary file to the data reloaded from the flash. But if there is a different result on compiling the sources twice..... forget it
riataman
@riataman
yeah, I don't think the compiler does reproducible builds ..
you can try I guess?
brutzler
@brutzler
Once on a project, I used this:
__DATE__ and __TIME__
on a html-page.
There I could see the compiling date and time.
Half the way....
Martin Ayotte
@martinayotte
I'm using those DATE and TIME since more than a year ...
brutzler
@brutzler
@martinayotte
for the same usage as I, or different?
Martin Ayotte
@martinayotte
@brutzler , simply to know the build timestamp.
dragon-engineer
@dragon-engineer
Guys, I just updated my 6 months old SDK for Arduino IDE for esp8266, and the same project that was 328kB large in size and needed 42kB in RAM now compiled under new SDK takes 422kB and needs 45.7kB RAM. I didn't update any libraries :worried: I mean, wtf is going around here?
Cristóvão Trevisan
@cristovao-trevisan
Probably due to ask
Sdk updates
Cristóvão Trevisan
@cristovao-trevisan
I just don't see any problems since the increase isn't so big
dragon-engineer
@dragon-engineer
well, FLASH is now 40%, + OTA upgrade so it is getting a little tight. RAM is bigger problem, because now the Async web server is noticeably slower..I'll do some more testing, however the reason I updated SDK was facing memory leaks after every request the server had to handle - is anyone using Igor's Async too? Even if I only send a few bytes of text, there is memory leak 500-700 bytes. I do not use any String / malloc and the heap is getting smaller with every request until it crashes
Me No Dev
@me-no-dev
@matasondrak first it’s my Async :D and then it does not leak ;) if it leaks, the issue would be in your code. I am open to be proven wrong though (on the leak)
oh and Igor is actually Ivan :P
dragon-engineer
@dragon-engineer
@me-no-dev thanks for the reply :smile: and for the info
I'll test only with one handler in the entire sketch
Me No Dev
@me-no-dev
async runs pretty low in lwip, so if an SDK update broke or introduced a change that could lead to leak, that is one possibility, but then that leak will be visible in the regular client/servers as well
dragon-engineer
@dragon-engineer
alright, I'm at work and I forgot the nodemcu module home so I'll test later.. but the fact that sdk update increased dramatically size of the sketch is a bit disturbing
Clemens Kirchgatterer
@everslick
@matasondrak the leaks you are seeing are probably sockets held in FIN_WAIT state. they get cleaned up after some time (minutes). the newer SDK limits the number of sockets in FIN_WAIT to something like 5 so the effect is less noticable.
dragon-engineer
@dragon-engineer

I found out what was the cause of the leaks.. it was this NotFound handler:

server.onNotFound({
AsyncWebServerResponse *response = request->beginResponse(SPIFFS, "/404.html");
response->setCode(404);

even if it was not written correctly, this code shouldn't normally run until I request a file that is not found on the server, right? I found it strange that with this code the sketch has memory leaks, even though I only refresh page /test.html

Me No Dev
@me-no-dev
you refresh /test.html but your browser also requests the little image that can show up in the title bar and since you do not request->send(response); you leak
dragon-engineer
@dragon-engineer
yes the favicon!! I forgot it! good point
Me No Dev
@me-no-dev
in any way and in any handler you should always respond to each request in some way
dragon-engineer
@dragon-engineer
yes definitely, that NotFound handler was your suggestion btw :smile: I asked you how to serve a SPIFFS static file in a custom handler and you sent me this, it worked so I didn't try it for stability/memory leaks
Me No Dev
@me-no-dev
never my idea not to actually request->send(response) ;)
dragon-engineer
@dragon-engineer
that's not it
Me No Dev
@me-no-dev
what is not it?
dragon-engineer
@dragon-engineer
ah sorry you are right, it's the ending of AsyncWebServerResponse *response = request->beginResponse(SPIFFS, "/404.html");
so what's better way? I asked here and got this solution suggested...
Me No Dev
@me-no-dev
server.onNotFound([](AsyncWebRequest * request){
  AsyncWebServerResponse *response = request->beginResponse(SPIFFS, "/404.html");
  response->setCode(404);
  request->send(response); //<<<very important line of code ;)
}
oops
dragon-engineer
@dragon-engineer
It's there.. I wrote it for the first time and then just omitted it
the problematic handler looks exactly like yours :smile:
Me No Dev
@me-no-dev
then it should not leak… I do not get it...
dragon-engineer
@dragon-engineer
yes, that's why I didn't test it earlier, nothing suspicious around
when I use request->send(404, "text/html", "404 Not Found"); it's all good
Me No Dev
@me-no-dev
what id you just request->send(SPIFFS, "/404.html”);
dragon-engineer
@dragon-engineer
unfortunately I didn't take my ESP module to work again :clap: so I can either send you a zipped solution with html or I'll do it myself in the evening
Me No Dev
@me-no-dev
you do have “/404.html”in the file system right?
dragon-engineer
@dragon-engineer
yes :smile:
Me No Dev
@me-no-dev
please do try tonight
dragon-engineer
@dragon-engineer
it serves the file but leaks
ok I will do the test
Me No Dev
@me-no-dev
how big is that file?