{"action":"created","issue":{"url":"https://api.github.com/repos/nodemcu/nodemcu-firmware/issues/452","labels_url":"https://api.github.com/repos/nodemcu/nodemcu-firmware/issues/452/labels{/name}","comments_url":"https://api.github.com/repos/nodemcu/nodemcu-firmware/issues/452/comments","events_url":"https://api.github.com/repos/nodemcu/nodemcu-firmware/issues/452/events","html_url":"https://github.com/nodemcu/nodemcu-firmware/issues/452","id":82520320,"number":452,"title":"node.getregistry() to mirror debug.getregistry() ","user":{"login":"TerryE","id":690173,"avatar_url":"https://avatars.githubusercontent.com/u/690173?v=3","gravatar_id":"","url":"https://api.github.com/users/TerryE","html_url":"https://github.com/TerryE","followers_url":"https://api.github.com/users/TerryE/followers","following_url":"https://api.github.com/users/TerryE/following{/other_user}","gists_url":"https://api.github.com/users/TerryE/gists{/gist_id}","starred_url":"https://api.github.com/users/TerryE/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/TerryE/subscriptions","organizations_url":"https://api.github.com/users/TerryE/orgs","repos_url":"https://api.github.com/users/TerryE/repos","events_url":"https://api.github.com/users/TerryE/events{/privacy}","received_events_url":"https://api.github.com/users/TerryE/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":10,"created_at":"2015-05-29T17:46:42Z","updated_at":"2015-06-21T15:14:15Z","closed_at":null,"body":"The lack of a debug implementation within the NodeMCU firmware is a bit of a limitation.  The one function that I really miss is `debug.getregistry()` as this pretty essential in understanding where memory leaks are occurring.  A simple work around would be to move this function into the node library.\r\n\r\nWith this, its quite easy to use a table walker to analyse what it being squirrelled away in the Lua registry and consuming RAM. \r\n\r\nThis only involves adding the function to `node.c`\r\n```Lua\r\nstatic int node_getregistry (lua_State *L) {\r\n  lua_pushvalue(L, LUA_REGISTRYINDEX);\r\n  return 1;\r\n}\r\n```\r\nand the extra entry to `node_map`\r\n```Lua\r\n  {LSTRKEY(\"getregistry\"), LFUNCVAL(node_getregistry)},\r\n```\r\nI'll implement this on my own build in the next week or so and if it proves useful, then I'll issue a pull request,  "},"comment":{"url":"https://api.github.com/repos/nodemcu/nodemcu-firmware/issues/comments/113912607","html_url":"https://github.com/nodemcu/nodemcu-firmware/issues/452#issuecomment-113912607","issue_url":"https://api.github.com/repos/nodemcu/nodemcu-firmware/issues/452","id":113912607,"user":{"login":"TerryE","id":690173,"avatar_url":"https://avatars.githubusercontent.com/u/690173?v=3","gravatar_id":"","url":"https://api.github.com/users/TerryE","html_url":"https://github.com/TerryE","followers_url":"https://api.github.com/users/TerryE/followers","following_url":"https://api.github.com/users/TerryE/following{/other_user}","gists_url":"https://api.github.com/users/TerryE/gists{/gist_id}","starred_url":"https://api.github.com/users/TerryE/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/TerryE/subscriptions","organizations_url":"https://api.github.com/users/TerryE/orgs","repos_url":"https://api.github.com/users/TerryE/repos","events_url":"https://api.github.com/users/TerryE/events{/privacy}","received_events_url":"https://api.github.com/users/TerryE/received_events","type":"User","site_admin":false},"created_at":"2015-06-21T15:14:15Z","updated_at":"2015-06-21T15:14:15Z","body":"@MarsTechHAN, @vowstar, in fact as well as the direct or indirect content of **_G** there are _two_ \"hidden\" means of context being stored between invocation success Lua callbacks:\r\n  *  Content stored in the Lua registry as is usually the case with data structures used by the Library routines for context. We've had a number of leaks that we've recently fixed related to these, in particular incorrect clean up of bugs in **tmr.alarm()** and **wifi.sta.getap()**.  This is what a `node.getregistry()` would expose.\r\n  *  What Ierusalimschy refers to as \"closed up values\".  This handling described in detail in Programming in Lua V3, but I've found [this draft paper](http://www.cs.tufts.edu/~nr/cs257/archive/roberto-ierusalimschy/closures-draft.pdf) by Ierusalimschy which cover this in depth in Section 3. And as shown in the following example:\r\n```Lua\r\n--  file a.lua\r\nlocal T= {1,2,3,4,5,\"hello world\"}\r\nlocal function getT() \r\n  return T \r\nend\r\n-- T is an open upvalue in getT at this point because T is still in scope\r\nreturn getT\r\n\r\n-- file x.lua\r\nlocal getT = dofile('a.lua')\r\n-- the outer frame of a.lua of A is now out of scope \r\n-- however because the closure refers to it, T still magically exists out of site\r\nprint (getT()[6]) \r\ngetT = nil\r\n-- Now T is a dead reference and can be GCed \r\n```\r\nI have enough problems getting my head around this.  It's no wonder that beginners regularly get burnt on it.  Hence my recommendation: avoid using upvalues (also known as outer scoped local variables) in callbacks -- stick to globals. "}}