Is there a technique for finding JsVar memory leaks?

[espruino-discuss]

Posted at 2015-10-31 by Kolban

I am examining the nature of the problems I personally introduce into the code base and I find that too many of them relate to failure to jsvUnLock created JsVar instances. Is there a technique that others use to diagnose such leaks? Ideally, I'd like to see a list of JsVars with their times of creation and their times of last access. I'm pretty sure that data isn't available in a JsVar object but maybe in a debug build such a thing might be useful.

[espruino-discuss]

Posted at 2015-10-31 by @allObjects

I'm not sure if this is of the help you are looking for to solve your problem... Automatic/hidden memory managment has come a long way and should become transparent to the 'user'. If memory leaks occur is to me an indication that the APIs are not clearly classified, and components that straddle both worlds - the automatic and self-managed world - are not properly implemented. Keeping the straddling components to a minimum and as simple and small as possible help to localize the issues. Localize not only in the sense of 'finding out' but also 'limit to a local impact'... which allow a narrow testing.

---

Posted at 2015-11-02 by @gfwilliams

Is there a technique that others use to diagnose such leaks?

Well, if you compile for Linux and make a test case in tests/foo.js then when you run the test, afterwards it'll shut down everything and will show you any variables that are left over.

Potentially you could do that exact same thing on ESP8266 if you want - just adding a few new lines in jsinteractive.c that copied what was done for save and then called jsvShowAllocated instead of save would probably do what you want.

Generally it's pretty obvious where they were created from what they are... For instance if you've got a bunch of ACCESS_POINT_SSID1, ACCESS_POINT_SSID2, etc then you can probably narrow it down to 1 line in scanAPs.