Current Lua downloadable firmware will be posted here

User avatar
By marcelstoer
#63964
gschulz wrote:I'm not sure you were looking at what you thought you were looking at. Firstly, if you were using the test code you presented, it would not have worked. When you modified my code, you eliminated the client:close() statement that would be necessary to kick off the next iteration.


Huh? You mean if the page says "Iterations: 140" in my browser after having refreshed in ~300ms intervals I shouldn't believe it?

Your feedback left me puzzled - at first. In my understanding the next iteration is primarily kicked off by the JavaScript reload in the browser not by closing the connection on the device.

Then I realized that the behavior depends on the browser. I was testing in Chrome. It closes/discards the connection even if the server doesn't explicitly close the connection on its end (due to `Connection: close` in the HTTP header I guess). So, it was all good but your comment (and jankop's) made me test with Safari and Firefox as well and they indeed only close the connection and reload after it times out.

gschulz wrote:moving the conn:on("send"...) callback to the conn:on("receive"...) callback should have no affect


You're right. I mixed up two things in haste. In terms of closed upvalues it's just essential that the "socket" in the on-receive callback is identified as `client` instead of re-using the `conn` variable.

So, I ran your unmodified code against 1.5.4.1 on ESP-01 with 512KB: all good, heap was stable (I stopped after 500 iterations). I did the same against 2.0 on a NodeMCU devkit: it eventually crashed.

And then it dawned on me. I had suspected from the very beginning that this might be another lw IP TIME_WAIT issue but I had dismissed that after my initial tests had succeeded.

Just two days ago we merged https://github.com/nodemcu/nodemcu-firmware/pull/1838 which fixes the above issue. So, I built another 2.0 firmware from the dev branch (latest revision) and ran your code again. And sure enough after an initial drop the heap stabilized. Considering the TIME_WAIT implications this makes total sense. After the test I killed the browser tab, waited a while and checked the heap again.

Code: Select all...
34864
=node.heap()
40184


Again, this makes sense. The difference between 35k and 40k are the sockets in TIME_WAIT that were cleared in the meantime.
User avatar
By jankop
#63968 I'm test
NodeMCU custom build by frightanic.com
branch: dev
commit: d9b3db06f6486505f215efdc04abda2f45a1cdee
SSL: false
modules: adc,bit,file,gpio,http,net,node,pwm,rtcmem,tmr,uart,wifi
build built on: 2017-03-19 21:30
powered by Lua 5.1.4 on SDK 2.0.0(656edbf)

and it's stabil.
Code: Select allIterations: 266 Heap: 36296
Version: 2.0.0
User avatar
By gschulz
#63981 Where did you get your build from? I just did a fresh build at nodemcu-build.com and it crashed after 75 iterations. How can I get a copy of your build?