-->
Page 1 of 1

PANIC: unprotected error in call to Lua API... and solution!

PostPosted: Tue Jun 09, 2015 6:55 pm
by kriegste
function listap(t) for k,v in pairs(t) do print(k.." : "..v) end end wifi.sta.getap(listap)

often causes a

PANIC: unprotected error in call to Lua API (stdin:2: bad argument #1 to 'pairs' (table or rotable expected, got nil))

The solution I found is this:
https://github.com/nodemcu/nodemcu-firm ... /435/files

Re: PANIC: unprotected error in call to Lua API... and solut

PostPosted: Tue Jun 09, 2015 11:01 pm
by cal
Moin,

Congratulations for making your way to the source.
I am not sure if this correction is the best one.
The specification of the function should tell what parameters the callback should get in case of scan errors.
If it defines that nil is passed you should have checked for this in your callback.
If there is some other way to see a difference between "no aps" and "error on checking" or that difference
is not important it's done.
Nevertheless it should be documented accordingly in api.

Cal

Re: PANIC: unprotected error in call to Lua API... and solut

PostPosted: Wed Jun 10, 2015 4:58 am
by kriegste
This callback is from one of the examples.

The PANIC crashes Nodemcu, causing a reset. Sometimes it hangs after the restart.

Re: PANIC: unprotected error in call to Lua API... and solut

PostPosted: Wed Jun 10, 2015 5:11 am
by cal
Lets say the implementation was right and API documentation was incomplete and should have been:

function(table): a callback function to receive ap table when scan is done
this function receive a table, the key is the ssid, value is other info in format: authmode,rssi,bssid,channel
In case of a scanning error the functions receives nil. Make sure to check for nil before accessing the parameter.



kriegste wrote:This callback is from one of the examples.

Someone wrote the example based on the API doc and because the API doc missed a case and is fixed now the example
needs to be fixed, too.
The PANIC crashes Nodemcu, causing a reset.

Thats good because of a bug in your program because you missed a case.
Better than hanging it does a reset.
Sometimes it hangs after the restart.


Thats a totally different aspekt. I expect that to be a result of using an older SDK. Newer SDKs seems to
have fixed some bugs in restart/init area.

You decided the implementation to be wrong. I say both views are valid.
In both cases the API need some addition to inform the user what happens with his callback in case of
an scanning error.


Cal