ESP8266 Community Forum

Posted: **Sat Jun 13, 2015 7:07 am**

When calling tmr.wdclr() to often it will leak memory.

Memory Leaking code

function forwardandrewind()
      if(forward == 1) then
         forward = 0
         gpio.write(3,gpio.HIGH)
      else
         forward = 1
         gpio.write(3,gpio.LOW)
      end
         
      for x=1,16000 do
         gpio.write(4,gpio.HIGH)
         tmr.delay(1)
         gpio.write(4,gpio.LOW)
         tmr.delay(1)
         tmr.wdclr()
      end

      print(node.heap())
end

Code that do not leak:

Code: Select all

function forwardandrewind()
      if(forward == 1) then
         forward = 0
         gpio.write(3,gpio.HIGH)
      else
         forward = 1
         gpio.write(3,gpio.LOW)
      end
         
      for x=1,16000 do
         gpio.write(4,gpio.HIGH)
         tmr.delay(1)
         gpio.write(4,gpio.LOW)
         tmr.delay(1)
         if(x%1000) then
              tmr.wdclr()
         end
      end

      print(node.heap())
end

Here i substitute the
tmr.wdclr()
with
if(x%1000) then
tmr.wdclr()
end

More info on this case can be found here:
viewtopic.php?f=24&t=3274&start=10#p18691

Posted: **Sun Jun 14, 2015 2:37 pm**

Hi, I posted a reply on the issue. I don't think that it is one. What are you trying to do here? I am not sure what is causing your leak, but have a read of my FAQ. What you are doing with your implementation is blocking other tasks from being scheduled, and this will cause other tasks to and task handling to backing up.

OK, if what you are doing works for you then it works for you, but you are pushing the firmware way beyond the envelope that it's been designed to operate in. The fact that weird thinks happen isn't a bug

Posted: **Sun Jun 14, 2015 3:19 pm**

Hi Terry,

I agree that the code should not loop that long. I think we (

) should add calls to tmr.wdclr() to the list of code smell
suspects. :geek:

But if it has a memory leak it may indicate a problem in nodemcu that needs inspection.

Cal

Posted: **Mon Jun 15, 2015 1:48 am**

Cal for a start this Lua not C so x%1000 always returns an integer (which evaluates true) so the code

Code: Select all

if(x%1000) then
  tmr.wdclr()
end

is just an inefficient way of always calling tmr.wdclr().

Whatever is manifesting itself here, it isn't a wdclr issue. If the O/P had included the actual heap values or a test which did both variants 20 times on a timer alarm and gave the two sets of heap values so we can see the solid trend then I would be more interested, but I do think that this is more probably a case of beginners confusion.

ESP8266 Community Forum

tmr.wdclr() leaks memory when called too often

tmr.wdclr() leaks memory when called too often

Re: tmr.wdclr() leaks memory when called too often

Re: tmr.wdclr() leaks memory when called too often

Re: tmr.wdclr() leaks memory when called too often