As the title says... Chat on...

User avatar
By cal
#16722 My congratulations that you found the problem yourself!

dnc40085 wrote:PROGRESS!!!!!1!!!!111!!!!11!1!!!1!!
I added stackdump() before and after each command that affects the Lua stack and learned how the stack is manipulated and where each function begins and ends. I figured out that the end of "wifi_scan_done" is the end of the line for the C function and I observed that when the function is done it does not remove the function stored in LUA_REGISTRYINDEX or set wifi_scan_succeed to "LUA_NOREF" so I added it. After this addition, the line "wifi.sta.getap(function() return end)" was no longer necessary and the memory use had dropped to 128 bytes.

This is what I added at the very end of wifi_scan_done:
Code: Select all  if(wifi_scan_succeed != LUA_NOREF)
  {
    luaL_unref(gL, LUA_REGISTRYINDEX, wifi_scan_succeed);
    wifi_scan_succeed = LUA_NOREF;
  }


This is the result:
Code: Select all=node.heap()
22072
> wifi.sta.getap(function(T) for k,v in pairs(T) do print(k..":"..v) end end)
>
> myssid:      1a:fe:34:xx:xx:xx,-1
xfinitywifi:      96:1a:ca:xx:xx:xx,-91
Linksys_dd-wrt:      00:1d:7e:xx:xx:xx,-64
=node.heap()
21944
>


Now I just have to figure out how to get the last 128 bytes back...


One important think that must be checked when registering lua based callbacks into some other framework
like here the SDK provided framework.
There will typically some handler written in c being used in between.

In that case you have to ask yourself some questions:

Must the callback be unregistered?
Can that be safely done?
Or may it happen that the callback may be called when the lua function is already being freed?
What can happen then?

You have to coordinate the life cycles of the registrations and the lua objects making up the lua part of the callback.

In our case this is no problem but there is an open issue in the "net" module where callbacks happen after
callback structure is freed and using the garbage inside some freed objects.

Have fun!

Cal
User avatar
By dnc40085
#16803
cal wrote:congratulations to the level of understanding you reached!

I would not have gotten to this point without your help, I am very grateful for the time you have invested in doing so. thank you very much.

Is that the famous wifi stack people are talking about. ;-) Didn't know that I could be dumped. ;-)
Shh, don't tell. it's a secret.

cal wrote:
Code: Select allc_sprintf(temp,"%d,%d,"MACSTR",%d", bss_link->authmode, bss_link->rssi,
                 MAC2STR(bss_link->bssid),bss_link->channel);
Why 32? Longest %d should be "-2147483647" = 11 bytes * 3 = 33 + other string chars. Better save than sorry.
If you know even less about your parameters there are safe versions of printf e.g. snprintf to avoid buffer overflows.
I went with 32 because, taking into account for the maximum values for each variable which I determined to be "4, -110, FF:FF:FF:FF:FF:FF, 13" it would take up 30 chars + null char, so in actuality it'd be 31 chars instead of 32.

cal wrote:My congratulations that you found the problem yourself!
Understanding is half the battle and without your assistance I'd probably still be trying to decipher the Lua C API to no avail. Again thank you very much.

A little bit earlier I submitted a pull request for the fix. Next, Using the info I've learned here, I'll be working on adding a few more functions to the wifi module (wifi.sta.getconfig(), wifi.sta.getrssi()) and upgrading some of the other ones to include more functionality/control.
Last edited by dnc40085 on Thu May 07, 2015 2:12 pm, edited 3 times in total.