Skip to content
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

WebServer memory leak (Rpi Pico W) #908

Closed
brabl2 opened this issue Oct 11, 2022 · 9 comments · Fixed by #914
Closed

WebServer memory leak (Rpi Pico W) #908

brabl2 opened this issue Oct 11, 2022 · 9 comments · Fixed by #914
Assignees

Comments

@brabl2
Copy link
Contributor

brabl2 commented Oct 11, 2022

Hi,
It looks there is a memory leak somewhere in the WebServer.
I only added this:
Serial.println(rp2040.getFreeHeap()); delay(20);
to the loop() in the AdvancedWebServer.ino example and found that the free heap decreases when any request is served by the WebServer.
According to my observations the free heap decreases by 88 bytes per each handled request regardless of data size sent out.

@brabl2 brabl2 changed the title WebServer memory leak WebServer memory leak (Pico W) Oct 11, 2022
@brabl2 brabl2 changed the title WebServer memory leak (Pico W) WebServer memory leak (Rpi Pico W) Oct 11, 2022
@revell1
Copy link

revell1 commented Oct 11, 2022

By adding a delay(20) you will also slow down the calls to "server.handleClient();".

Try removing that delay, and instead use a loop count to regulate your reporting of free heap.

@brabl2
Copy link
Contributor Author

brabl2 commented Oct 11, 2022

I replaced the reporting by this one:
if (++i>=100) {i=0; Serial.println(rp2040.getFreeHeap());}
However the behavior is same.
The free heap decreases by 88 bytes per each handled request.

@revell1
Copy link

revell1 commented Oct 11, 2022

OK.
Well that did not work, but atleast it will not be slowing the calls to handleClient().

Try replacing

if (++i>=100) {i=0; Serial.println(rp2040.getFreeHeap());}

With something like the following, where you only print the freeheap when i is 100, but print an integer value
when i is 200. Also using a variable to hold the heapfree value, rather than in the Serial.println call.
Should get the same rate of calls to println(), but half the rate of calls of getFreeHeap() so should see a change in the drift.

if (i==100) {numBytes = rp2040.getFreeHeap());Serial.println(numBytes);}
if (++i>=200) { i=0; Serial.println(12345);}

To see if it is the call to Serial.println() or rp2040.getFreeHeap() that is causing a problem.

I have been using rp2040.getFreeHeap() without issue to report heap space in a web server response, and it sits at a stable value (it initially reduces a little, but then is stable).

@brabl2
Copy link
Contributor Author

brabl2 commented Oct 11, 2022

It is a misunderstanding.
I'm not reporting issue in Serial.println() nor rp2040.getFreeHeap(). None of these two is causing the heap leak.
I'm reporting issue in WebServer.
I used the Serial.println(rp2040.getFreeHeap()); to show the leaking heap when using the AdvancedWebServer.ino example.
The size of free heap is approx. 190000 bytes at the start.
Based on my test each request handled by WebServer causes 88 bytes leak, so after approx. 2160 handled requests the AdvancedWebServer.ino example dies since there is no memory available.
I'm using the latest arduino-pico release 2.6.0

@revell1
Copy link

revell1 commented Oct 11, 2022

Hi, sorry, yes a bit of a misunderstanding, I had used this example previously and did not have a problem with memory leak, but I think that was back with version 2.5.2.

Now when I rebuild my SAVED project, it builds and runs, but if I add printing of heap, I also get an 88 byte reduction for each transfer request, i.e. the HTML and then the SVG file, so two times 88 per web page refresh.

So I can not tell if this is something that existed back with version 2.5.2 or has been added recently with some update to the code base, however I think this must be a new bug (see an old issue 860 that I raised some time back).

But I CAN CONFIRM your report.

@earlephilhower Earle, you probably recall issue 860 this memory leak could not have been present at that time as you were managing to run the EXAMPLE code for an extended period, and should have run out of memory during those tests. This would suggest the bug has been introduced since 2.5.2.

Also Earle, the code is using a variable "led" of 13, I guess this is a special GP pin output for an LED, would make sense if the onboard LED could be used for this indication, unless you are using the pin for some hardware scope test setup.

@earlephilhower
Copy link
Owner

Very odd, but reproducible on my end, too. I was using FireFox and I think that maybe it put the tab to sleep since it wasn't at the forefront so while the uptime was many hours on my prior testing, the actual number of page pulls wasn't so great.

@earlephilhower
Copy link
Owner

There was a lost client structure each connection.

I just laid on the F5 key and memory is very stable with the PR #914 (updated demo to include memory and page serve count)
image

@earlephilhower
Copy link
Owner

@brabl2 @revell1 I suggest you give #916 a try.

After I fixed the memory leak I was still getting random crashes or hangs, so I did a lot more debugging and think I have it pretty solid now with that PR.

@brabl2
Copy link
Contributor Author

brabl2 commented Oct 20, 2022

The WebServer reliability was improved with these two fixes (tested with Firefox and Vivaldi).
Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants